Nitsan Seniak : « La technologie pour la technologie ne m’a jamais intéressé »

Il a contribué à construire un produit devenu un business de 200 millions de dollars d’ARR, dirigé des équipes de 200 personnes, connu le rachat par IBM, l’échec entrepreneurial, les huissiers, les licenciements et les infrastructures capables d’absorber 600 000 événements par seconde. À chaque étape, Nitsan Seniak est revenu à la même conviction : la technologie n’a de valeur que lorsqu’elle résout un problème pour quelqu’un. Une idée qui façonne aujourd’hui sa vision du management, du recrutement et de l’intelligence artificielle.

Enfant, Nitsan Seniak n’a pas encore d’ordinateur.

Il a pourtant déjà décidé qu’il deviendra développeur.

La première machine qu’il aperçoit se trouve dans un laboratoire universitaire. Le père d’un camarade de classe, chercheur, leur fait visiter les lieux. Nitsan regarde les adultes taper sur un clavier et recevoir une réponse de la machine. Il reste figé devant l’écran.

Il veut comprendre.

À l’époque, un ordinateur personnel coûte cher. Il économise pendant plusieurs années. En attendant de pouvoir en acheter un, il se procure un manuel de programmation et écrit du code sur papier. Des milliers de lignes qu’il recopie patiemment dans des cahiers, sans pouvoir les exécuter ni vérifier qu’elles fonctionnent.

Le jour où il reçoit enfin son ordinateur, il saisit tout.

Presque rien ne marche.

Ce souvenir pourrait résumer une grande partie de sa carrière. Construire, tester, se tromper, comprendre, recommencer. Non pas par amour abstrait de la technique, mais pour voir une idée devenir réelle.

« La technologie pour la technologie ne m’a jamais intéressé. Ce qui me motive, c’est de résoudre des problèmes pour des gens. »

Les machines ont changé. Les langages aussi. Mais cette conviction n’a pas bougé.

Créer quelque chose qui arrive jusqu’aux autres

Adolescent, Nitsan vend son premier logiciel. Un programme destiné à produire de la musique électronique, acheté par un petit éditeur parisien.

La somme est modeste. L’effet, beaucoup moins.

Pour la première fois, le code qu’il a écrit quitte sa chambre. Quelqu’un d’autre va l’utiliser.

Il poursuit ensuite des études d’informatique jusqu’au doctorat, convaincu que la recherche représente le sommet de la discipline. Il y découvre des sujets passionnants, mais aussi un environnement qui lui correspond mal.

Ce qui le dérange n’est pas la difficulté intellectuelle. C’est la compétition entre individus.

Nitsan comprend qu’il n’a pas envie de construire seul contre les autres. Il a besoin de coopération, d’objectifs communs, d’une équipe.

La compétition entre entreprises le motive. La politique interne, beaucoup moins.

Il quitte donc la recherche après sa thèse et rejoint ILOG, l’une des rares entreprises technologiques françaises de l’époque. La société travaille notamment sur les systèmes experts, une première forme d’intelligence artificielle fondée non pas sur l’apprentissage, mais sur des ensembles de règles capables de reproduire certains raisonnements humains.

Il entre chez ILOG comme développeur.

Il y apprendra surtout à devenir manager.

Sa première erreur de management

Quelques années après son arrivée, Nitsan prend la direction d’une petite équipe chargée de transformer un moteur technologique en véritable produit commercial.

Le produit fonctionne. Il rencontre son marché. L’équipe grandit.

Puis elle grandit encore.

Nitsan se retrouve progressivement à la tête de 70 personnes. Il structure les responsabilités, organise les processus, clarifie les méthodes de travail. Sur le papier, tout est propre.

Humainement, beaucoup moins.

Il est tellement concentré sur le produit, l’organisation et l’efficacité qu’il ne voit pas la démotivation s’installer. Il ne prend pas suffisamment le temps de comprendre ce que les membres de son équipe veulent apprendre, ce qui les inquiète ou ce qui donne du sens à leur travail.

L’organisation fonctionne. L’équipe, non.

« J’étais complètement obsédé par le fait de bien organiser l’équipe et d’avoir les bons process. Je ne faisais pas la partie humaine du management. Ça m’a explosé à la tête. »

Une consultante l’aide alors à reprendre le sujet autrement. À écouter avant de structurer. À considérer les aspirations individuelles comme une composante du travail, et non comme une distraction.

Cette erreur deviendra l’un de ses principaux repères.

Le management ne consiste pas à faire entrer des personnes dans une organisation parfaite. Il consiste à créer un cadre dans lequel elles peuvent bien travailler ensemble.

Le produit développé par son équipe contribue à la croissance d’ILOG, puis à son rachat par IBM. Nitsan reste pour accompagner l’intégration de ses collaborateurs. Il dirige bientôt une organisation internationale d’environ 200 personnes, réparties entre plusieurs pays.

Il y découvre qu’au-delà des différences culturelles, les attentes fondamentales changent peu.

Les individus veulent être respectés. Ils veulent comprendre ce que l’on attend d’eux. Ils veulent disposer d’une forme d’autonomie. Ils veulent pouvoir faire leur travail sans être considérés, par défaut, comme des personnes qu’il faudrait surveiller.

IBM lui permet de découvrir le fonctionnement d’une organisation mondiale, avec des équipes réparties dans plusieurs pays et des problématiques de coordination à très grande échelle.

Cette expérience l’aide aussi à préciser le type d’environnement dans lequel il s’épanouit le mieux.

Dans une organisation de cette taille, les différentes couches de management peuvent parfois s’éloigner du produit et du travail quotidien des équipes. Nitsan comprend alors qu’il préfère les structures plus directes, où la confiance circule facilement et où chacun reste proche du problème collectif à résoudre.

La technologie est toujours là. Mais pour lui, elle n’a de sens que si elle reste connectée à celles et ceux qui la construisent et l’utilisent.

Un bon produit ne suffit pas

Après IBM, Nitsan veut aller au bout de l’aventure. Il crée une entreprise avec deux anciens collègues.

Ils construisent un produit solide. Techniquement, il fonctionne. Il rend un véritable service. Mais presque personne ne le sait.

L’entreprise ne trouve pas son marché.

Nitsan découvre alors une vérité qui paraît évidente une fois qu’on l’a comprise : construire un bon produit et savoir le distribuer sont deux métiers différents.

« Si personne n’est au courant, cela ne sert à rien. L’acquisition est un métier à part entière. Et c’est très difficile. »

Les deux autres associés finissent par partir. Nitsan continue seul pendant six mois, davantage par obstination que par conviction. Puis il arrête.

L’échec est douloureux, mais encore lisible. Le produit n’a pas trouvé son public. Des erreurs ont été commises. Il peut les analyser.

L’expérience suivante est plus brutale.

Dans une deuxième aventure entrepreneuriale, les financements promis n’arrivent pas correctement dans la filiale française qu’il dirige. Les salaires sont versés de manière irrégulière. Les prestataires et les cotisations restent impayés.

Un jour, des huissiers frappent à la porte de son domicile.

Nitsan essaie de protéger sa famille, tait une partie de ses difficultés, somatise. Il finira par quitter l’entreprise et récupérer plusieurs années plus tard les salaires qui lui étaient dus.

Mais le dommage ne se résume pas à une somme.

Il vient de comprendre que la confiance ne dispense jamais de vérifier. Le discours d’un associé, son assurance ou son passé supposé ne remplacent pas une véritable vérification des faits.

Après plusieurs projets difficiles, le doute s’installe.

« Je me suis demandé si je n’étais pas devenu mauvais. Peut-être que tout ce que j’avais réussi avant n’était que de la chance. »

Ce doute est moins spectaculaire qu’une faillite ou qu’une visite d’huissier. Il est pourtant plus profond. Il ne porte plus sur un projet. Il porte sur sa propre capacité à construire.

Recruter pour créer une culture, pas pour remplir un organigramme

Lorsqu’il rejoint Iziwork, Nitsan cherche un projet suffisamment ambitieux pour se prouver qu’il peut encore réussir.

L’entreprise veut digitaliser le marché de l’intérim. Elle dispose de moyens importants et doit construire sa plateforme rapidement. Nitsan arrive parmi les premiers profils techniques et fait un choix immédiat : il ne codera pas.

Pas parce qu’il n’aime plus cela.

Parce qu’il sait qu’il ne pourra pas être à la fois le premier développeur et la personne chargée de bâtir une équipe de grande ampleur.

En un an et demi, il recrute environ 70 personnes.

Cette période transforme sa vision du recrutement. Jusque-là, il avait recruté ponctuellement. Il doit désormais créer un système capable d’identifier rapidement les personnes qui pourront travailler ensemble dans la durée.

Son premier filtre n’est pas technique.

Ce sont les valeurs.

Pour Nitsan, une équipe ne devient pas performante simplement parce qu’elle rassemble les meilleurs spécialistes. Elle fonctionne lorsque ses membres partagent une même manière d’envisager le travail, la responsabilité et le produit.

Il cherche des développeurs qui s’intéressent à l’utilisateur final. Des personnes capables de dépasser leur périmètre. Des profils qui ne considèrent pas qu’une tâche est terminée dès que le code a été écrit.

Le niveau technique reste indispensable. Mais il ne compense pas une incompatibilité profonde dans les façons de travailler.

Une compétence peut progresser. Une conception opposée de la responsabilité collective crée des frictions permanentes.

Nitsan formalise donc les valeurs qu’il recherche et prépare des questions capables de faire émerger des comportements réels. Il ne veut pas entendre un candidat expliquer qu’il apprécie le travail d’équipe. Il veut comprendre ce qu’il fait lorsqu’un incident survient, lorsqu’un collègue se trompe ou lorsqu’une décision produit ne correspond pas à sa préférence technique.

Recruter par les valeurs ne signifie pas recruter des copies conformes.

Cela signifie construire un socle commun suffisamment solide pour permettre les désaccords.

Cette approche explique peut-être pourquoi plusieurs développeurs l’ont suivi d’une entreprise à l’autre. Certains étaient entrés dans ses équipes comme stagiaires. Des années plus tard, ils ont accepté de retravailler avec lui.

Ils connaissaient son niveau d’exigence.

Mais ils savaient aussi qu’il les protégerait.

Le rôle invisible du CTO

Chez Iziwork, Nitsan mesure concrètement ce que signifie protéger une équipe.

À mesure que l’entreprise grandit, les attentes se multiplient. Il faut aller vite, structurer, recruter et maintenir un haut niveau d’exigence. Dans ce contexte, son rôle ne consiste pas seulement à organiser la production technique.

Il doit aussi préserver un cadre de travail cohérent malgré cette pression.

Cela passe par des décisions très concrètes : défendre un collaborateur lorsqu’il estime qu’un jugement est injuste, résister à des indicateurs qui simplifieraient trop la réalité du travail des développeurs, ou encore éviter que la pression ne se diffuse mécaniquement dans l’équipe.

C’est une fonction rarement visible du CTO.

Traduire, protéger, absorber une partie de la pression et décider de ce qui ne doit pas descendre plus bas.

Pendant quatre ans, Nitsan reste parce qu’il est fier du produit construit, de l’équipe créée et des personnes qu’il a convaincues de le rejoindre.

Cette expérience lui apprend qu’un CTO n’est pas seulement responsable de la technologie. Il est aussi responsable du cadre dans lequel elle se construit.

Et que la confiance entre les fondateurs, les managers et les équipes reste une condition essentielle pour durer.

Trouver des fondateurs capables de faire confiance

Lorsqu’un chasseur de têtes lui propose de rencontrer les fondateurs de MEE6, le poste n’existe pas vraiment.

La société cherche plutôt un profil produit. Le recruteur pense pourtant qu’une rencontre peut fonctionner.

Le fit est immédiat.

Les deux fondateurs sont beaucoup plus jeunes que Nitsan. Cela ne crée aucune difficulté. Ils sont ambitieux sans chercher à masquer ce qu’ils ignorent. Ils comprennent la technologie, valorisent son expérience et ne considèrent pas la pression comme un outil de management.

Surtout, la confiance circule dans les deux sens.

Après les expériences précédentes, c’est devenu son principal critère.

MEE6 a été lancé très tôt dans l’histoire de Discord. Le bot est rentable, largement adopté et porté par une équipe encore réduite. Pendant la période du Covid, l’usage de Discord accélère fortement. Les fondateurs décident de structurer une véritable entreprise et recrutent Nitsan pour accompagner ce passage à l’échelle.

Il reproduit ce qu’il avait appris chez Iziwork et recrute rapidement une vingtaine de développeurs.

Puis la croissance ralentit.

L’effet Covid s’estompe. Discord progresse moins vite. La concurrence augmente. Les coûts de l’entreprise ont grandi en anticipant une trajectoire qui ne se réalise pas.

Trois vagues de licenciements suivent.

Nitsan doit se séparer de personnes qu’il a lui-même convaincues de venir, dont certaines appartiennent à son réseau depuis des années.

Il ne cherche pas à présenter cette période comme une réussite. Licencier reste une expérience pénible. Mais la manière compte.

Les raisons sont exposées clairement. Les conditions de départ sont négociées pour être aussi correctes que possible. La décision économique n’est pas transformée en jugement personnel.

Une entreprise peut être contrainte de réduire son équipe sans retirer leur dignité aux personnes qui partent.

600 000 événements par seconde, et une petite équipe pour les absorber

Derrière son apparente simplicité, MEE6 opère à une échelle considérable.

Le bot est présent dans des millions de communautés. Chaque interaction sur Discord peut générer un événement. Au plus fort de l’activité, l’infrastructure doit en absorber environ 600 000 par seconde.

Le défi n’est pas seulement de traiter ce volume.

Il faut le faire rapidement, de manière fiable et à un coût soutenable. Ajouter indéfiniment des serveurs résoudrait une partie du problème technique tout en détruisant l’équation économique.

À son arrivée, les incidents sont fréquents. Deux ou trois fois par semaine, le service peut se dégrader ou s’interrompre. L’équipe répare dans l’urgence, parfois le soir ou le week-end.

À cette fréquence, la maintenance finit par consommer toute la capacité de création.

Nitsan et son équipe renforcent alors l’observabilité de la plateforme. Ils collectent davantage de signaux, identifient les dégradations avant qu’elles deviennent critiques et automatisent une partie des réponses.

L’objectif n’est pas de produire l’architecture la plus élégante.

Il est de permettre à une petite équipe de maintenir une plateforme massive sans passer sa vie à éteindre des incendies.

Encore une fois, la technologie reste un moyen. La vraie mesure du succès est humaine : moins d’alertes nocturnes, moins d’épuisement et davantage de temps consacré au produit.

Revenir au code pour redevenir utile

Après les différentes réductions d’effectifs, l’équipe technique ne compte plus que quelques personnes expérimentées.

Nitsan va voir les fondateurs.

Il avait été recruté pour construire et manager une organisation en croissance. Il ne recrute plus. Il n’a presque plus rien à manager. Il leur propose de partir.

Ils préfèrent qu’il reste. L’entreprise cherche encore de nouveaux relais de croissance et pourrait avoir besoin de lui si elle repart.

Nitsan accepte, à une condition implicite : retrouver une utilité immédiate.

Il recommence à coder.

Ce retour n’a rien d’un geste nostalgique. Il ne cherche pas à prouver qu’il est encore capable d’écrire une fonction ou de corriger un bug. Il revient au code parce que c’est désormais l’endroit où il peut contribuer le plus directement.

Et parce qu’il aime toujours cela.

Le moment est particulier. Après des années loin du développement quotidien, il retrouve le métier précisément lorsque l’intelligence artificielle commence à le transformer.

D’abord avec l’autocomplétion. Puis avec des assistants capables de comprendre une demande, de modifier plusieurs fichiers et de produire des pans entiers d’une fonctionnalité.

S’il était resté un CTO entièrement détaché du code, il aurait observé cette révolution à travers des articles, des conférences ou les retours de ses équipes.

En la pratiquant lui-même, il en comprend les forces, les limites et les conséquences concrètes.

Pourquoi les meilleurs développeurs peuvent résister à l’IA

L’un des paradoxes observés par Nitsan est que les développeurs les plus expérimentés ne sont pas toujours les premiers à adopter ces outils.

Ils ont de bonnes raisons.

Un développeur senior a construit au fil des années une manière de travailler qui lui permet d’être performant. Il connaît ses outils, ses raccourcis et ses méthodes. Chaque nouvelle promesse technologique représente aussi un risque de perdre du temps, de dégrader la qualité ou de remplacer un système maîtrisé par un gadget imposé par le management.

Cette prudence peut ressembler à du conservatisme. Elle est souvent le produit de l’expérience.

Pour les convaincre, Nitsan ne croit ni aux discours ni aux obligations.

Il expérimente. Il montre. Il crée un effet de surprise en réalisant rapidement une tâche qui aurait auparavant demandé beaucoup plus de temps.

L’adoption vient lorsque les développeurs voient une amélioration réelle dans leur propre travail.

Pas lorsqu’un dirigeant leur demande d’utiliser davantage l’IA.

Il se méfie particulièrement des entreprises qui transforment l’usage de ces outils en indicateurs individuels : nombre de requêtes, volume de tokens consommés ou budget dépensé.

Dès qu’une mesure devient un objectif, elle cesse souvent de mesurer ce qu’elle devait représenter. Un collaborateur peut augmenter artificiellement sa consommation d’IA sans mieux travailler ni apprendre quoi que ce soit.

On obtient alors une conformité visible, pas une transformation.

L’enjeu n’est pas que les développeurs utilisent l’IA.

L’enjeu est qu’ils découvrent les situations dans lesquelles elle leur permet de mieux construire.

L’IA révèle ce que les développeurs aiment vraiment

Pour Nitsan, l’arrivée de l’intelligence artificielle rend la distinction entre deux profils encore plus importante.

Il y a les développeurs passionnés par la fabrication de la technologie elle-même : écrire du code, résoudre une difficulté algorithmique, concevoir une architecture élégante.

Et ceux qui voient le code comme le moyen de faire exister un produit.

Les deux approches peuvent produire d’excellents ingénieurs. Mais elles ne réagissent pas de la même manière à l’IA.

Pour le premier profil, l’assistant peut ressembler à un concurrent. Il prend en charge une partie du travail qui procurait précisément du plaisir.

Pour le second, il devient un multiplicateur. Il réduit la distance entre une idée et sa mise à disposition des utilisateurs.

Nitsan appartient clairement à cette deuxième catégorie.

Écrire chaque ligne lui-même ne lui manque pas. Ce qu’il aime, c’est voir le produit avancer.

Le code lui a toujours semblé être ce qui se rapproche le plus d’un superpouvoir : quelques instructions suffisent pour créer un système capable d’agir dans le monde. Avec l’IA, dit-il, ce pouvoir est démultiplié.

Cette évolution modifiera aussi la structure des équipes.

Une entreprise conçue dès le départ autour des assistants, des automatisations et de nouvelles pratiques de développement pourra probablement accomplir avec trois personnes ce qui aurait autrefois nécessité une équipe de trente.

Cela ne signifie pas la disparition des développeurs.

Cela déplace leur valeur.

Le développeur de demain devra comprendre davantage que le code

L’IA sait déjà produire rapidement du code plausible. Elle sait moins bien comprendre pourquoi une fonctionnalité doit exister, quelles contraintes économiques elle doit respecter ou comment elle s’inscrit dans l’ensemble d’un produit.

Elle peut répondre correctement à une demande qui était mal formulée.

Elle peut construire quelque chose de logique, mais contraire à l’objectif réel.

Le rôle du développeur se déplace donc vers le contexte, l’architecture, l’intention et l’arbitrage.

Pour Nitsan, les profils les plus précieux seront ceux qui comprennent toute la chaîne : la technique, mais aussi le produit, le design, l’expérience utilisateur et le business.

Pas pour remplacer chaque spécialiste.

Pour être capables de donner à l’IA le bon contexte, d’évaluer son travail et de relier une décision technique à un objectif plus large.

Il recommande aux développeurs seniors d’expérimenter sans se fixer trop vite de limites. De confier aux outils des tâches qu’ils pensent peut-être encore impossibles. D’accepter d’échouer pour découvrir précisément où se trouve la frontière.

Il invite aussi à repenser les produits eux-mêmes.

Ajouter un assistant dans un logiciel existant ne suffit pas. Les nouveaux entrants capables de concevoir une expérience entièrement organisée autour de l’IA pourront remettre en cause des acteurs historiques qui se contentent de greffer quelques fonctionnalités génératives sur leurs interfaces.

Un ATS, par exemple, ne serait plus nécessairement pensé d’abord comme une succession de pages, de boutons et de formulaires. Il pourrait commencer par une conversation capable de croiser les informations du recrutement, des e-mails et des autres outils de l’entreprise.

L’interface graphique resterait utile.

Mais elle ne serait plus forcément le centre du produit.

Construire reste une aventure collective

Nitsan Seniak cherche désormais un projet suffisamment early pour lui permettre d’utiliser toute l’étendue de son expérience.

Coder au début. Poser les fondations. Comprendre le produit. Puis accompagner sa croissance et structurer l’équipe lorsque le besoin apparaît.

Il ne cherche plus un titre pour lui-même.

Il cherche un contexte dans lequel il pourra être utile.

Le projet devra placer la technologie au cœur de sa valeur. Il devra aussi être porté par des fondateurs avec lesquels la confiance peut exister dans les deux sens.

Le reste est secondaire.

Depuis ses premières lignes de code, les technologies ont changé.

Les langages ont changé.

Les architectures ont changé.

L’intelligence artificielle est arrivée.

Mais une chose est restée la même.

Derrière chaque ligne de code, il y a des femmes et des hommes qui choisissent de construire ensemble.

Et c’est peut-être cela, le véritable rôle d’un CTO.

Article rédigé à partir de l’entretien réalisé par Bluecoders avec Nitsan Seniak le 12 juin 2026.