Quand l’IA vient remettre en cause ma conception du métier

Si vous suivez assidument cette newsletter, vous aurez probablement remarqué que je n’ai pas posté depuis un petit moment. La raison première est une période très chargée dans laquelle je ne m’autorise pas facilement les quelques heures nécessaires à l’écriture d’un article de fond. Mais si je veux être complètement honnête, il y a une autre raison à cette absence d’écriture. J’ai du mal à me lancer, je suis même un peu perdu.

Je crois que les humains sont les seuls animaux que nous connaissons qui inventent des outils pour travailler ensemble, et ils le font depuis aussi longtemps que nous les considérons comme humains.

Cette citation de Gerald Weinberg est dans ma bio LinkedIn depuis des années. Quand on me demande quelle est la qualité principale d’un·e bon·ne développeur·se (dans un contexte professionnel) je dis sans sourciller que c’est la capacité à travailler en équipe.

Quand on va au delà du POC ou du side project, les process d’industrialisation du développement logiciel consistent à aligner les pratiques pour délivrer efficacement de la qualité à la maille d’une équipe (quelle que soit sa taille). Ça passe par des rituels quotidien de partage, par des revues entre pairs, par de la traçabilités des décisions collectives…

Ces moments de collaboration, qu’ils soient synchrones où asynchrones, reposent sur un équilibre plutôt sain entre le temps passé à concevoir, le temps passé à réaliser et le temps passé à vérifier. Avec le bon dosage de moments d’échange et de périodes de “focus“. C’est un équilibre qui n’est pas toujours facile à trouver mais c’est une cible assez claire et globalement intuitive autour de laquelle les équipes de développement s’organisent. Le travail du CTO consiste (entre autre) à trouver et maintenir cet équilibre.

Mais ça … c’était avant

L’arrivée de l’IA bouscule l’un de ces paramètres, le temps passé à réaliser. Et c’est tout l’équilibre qui est chamboulé.

Tous les secteurs de cols blancs sont impactés d’une façon ou d’une autre par l’IA générative, mais l’informatique à ceci de particulier que la matière produite, le code, est particulièrement adapté aux LLM. Les langages informatiques sont conçus pour répondre à la logique et la structure, ils sont globalement dénués de subtilité ou d’ambiguïté. C’est un terrain de jeu parfait pour les modèles de langage.

Et ça se voit dans l’évolution de leur impact. En 18 mois on est passé d’une écriture de code qu’on pourrait qualifier d’organique (avec un peu d’auto-complétion et d’aide au débug) à du vibe coding… puis du context engineering… et maintenant harness engineering…

La façon dont les choses changent est assez folle.

Comme beaucoup de confrères, j’ai construit ma roadmap 2026 en anticipant les besoin métiers, les risques RH, en imaginant les obstacles financiers, en créant des potentielles d’opportunités architecturelles… à aucun moment je ne me suis douté que mon problème le plus important cette année serait d’entendre trop souvent ces 6 mots :

Je n’ai plus de token.

Je disais en introduction que j’écris moins car je suis perdu. C’est vrai.

Ces changements, et leur rythme, me font poser tout un tas de questions. C’est une charge mentale assez dingue, et des convictions qui sont remises en question aussi vite qu’elles se forgent.

Les questions que je me pose en ce moment sont nombreuses, leurs réponses sont peut-être aussi pertinente aujourd’hui qu’elles seront hors sol dans 6 mois. En voici quelques unes (liste non exhaustive…) :

• La question “Make it or buy it“ a-t-elle toujours du sens quand je peux “make“ en quelques prompt un soft qui correspond exactement à mon besoin ?

• L’avenir du développement passe-t-il par des “one-wo·man teams” ? Comment on s’assure que pour progresser on peut toujours débattre ? co-construire ?

• Qu’est-ce qui défini la maintenabilité du code qui a été écrit, mais surtout qui sera modifié, par des agents IA ?

• Est-ce que “You build it, you run it” est toujours un paradigme pertinent si on peut livrer un nouvel outil tous les mois ?

• Comment on découpe les architectures applicatives pour éviter la concurrence d’écriture de code sur un même outil ?

• Comment on adapte les infrastructures pour héberger cet applicatif ?

• Est-ce que le besoin informatique est infini ? Quels sont les nouveaux goulots d’étranglement ? Comment on prend les décisions quand le principal critère de choix, le coût du développement, est fondamentalement remis en question ?

• Comment on assure la qualité ? le testing ? Comment on adapte la conception à une capacité ultra rapide de “test and learn“ ? Quelles sont les feedback loops de demain ?

• Quels sont les nouvelles bases sur lesquels on va former nos juniors ?

• and so on …

Et tout ça avec un business model basé sur les tokens, une unité de mesure sur laquelle on a assez peu d’emprise et dont les principaux fournisseurs nous ont déjà montré qu’ils sont capable d’en changer la valeur significativement et sans aucune forme de procès (alors qu’on se remet encore à peine du trauma de Google Maps).

Je suis perdu …

Mais aussi perdu que je sois, j’ai rarement été aussi enthousiaste.

Mon choix de passer du métier de développeur à celui de manager était intrinsèquement motivé par ces sujets d’organisation du travail dans une équipe de dev. Ces questions qui se bousculent dans ma tête sont exactement celles auxquelles j’aspire répondre.

Je ne me fais pas d’illusion, je sais que les réponses ne seront pas évidentes, qu’il va falloir se creuser la tête pour y répondre, que je vais me tromper. Il va me falloir l’humilité de l’admettre tout en ayant suffisamment de certitudes pour guider une équipe dans ce flou artistique.

Il va falloir s’accrocher à ses convictions pour y arriver, et je connais les miennes.

La première, celle que j’ai chevillée au corps depuis des années et que j’ai vérifié par l’expérience, c’est la nécessité, dans un domaine qui bouge vite, de mettre la collaboration au cœur des process, d’apprendre par la confrontation d’idées, par la remise en question entre pairs.

La seconde a été formulée dans le manuel de formation des collaborateurs d’IBM avant ma naissance et est encore plus d’actualité aujourd’hui. « A computer can never be held accountable, therefore a computer must never make a management decision » Rien n’est plus important aujourd’hui que de maîtriser et savoir défendre son travail.

On vit une vrai révolution. Je racontais en conférence il y a quelques années que j’étais redevenu junior en passant de développeur à manager. Je retrouve aujourd’hui ce sentiment. Les transformations qui s’opèrent sont à la frontière entre la technique et l’humain, exactement là où j’aime me creuser les méninges. Le fait de construire ce que sera l’informatique de demain a quelque chose de grisant.

Pour autant, je garde en tête que le contexte n’est pas simple. Vous connaissez mes préoccupations autour de l’autonomie stratégique et du numérique responsable. C’est un prisme au travers duquel je me dois de regarder ces sujets, et que je continue évidemment d’aborder dans cette newsletter.

Mais on va prendre cette foutue pilule rouge. On reste au Pays des Merveilles, et on va voir jusqu’où va le terrier.