La vitesse que l’IA apporte au code est intéressante, parce qu’elle est loin d’être aussi uniforme que les gens l’imaginent.
Je regardais mon graphique de contributions GitHub ce matin et je pensais à ça.
Vous verrez des périodes avec des centaines de contributions en une journée, réparties sur six projets. Puis ça tombe à cinq. Ou trois. La semaine dernière, j’ai eu une journée avec deux contributions, 11 000 lignes de code et environ 150 000 lignes de documentation qui touchaient six dépôts.
Ce genre de schéma paraît bizarre jusqu’à ce qu’on comprenne en quoi consiste réellement le travail.
L’ingénierie du contexte
Tout le travail sur une application n’est pas de l’implémentation.
Une partie est exploratoire. On teste des trucs qui ne finiront peut-être jamais dans le projet final.
Une autre partie est de la planification. Et même si la planification est radicalement accélérée quand on utilise bien l’IA, ça reste la partie la plus laborieuse de tout projet sérieux.
C’est exactement comme ça que ça doit être.
En fait, ne pas planifier est l’une des plus grosses erreurs qu’on puisse commettre aujourd’hui.
En tant qu’industrie, on a toujours sous-évalué la planification et la documentation. L’IA n’a rien changé à ça. Elle a juste rendu les conséquences impossibles à ignorer.
Quand la vitesse de production augmente, un processus bancal cesse d’être une nuisance pour devenir une charge de démolition.
La façon de concevoir la documentation à l’ère du code par IA, c’est de la voir comme une infrastructure de contexte et un façonnage comportemental.
Que vous le vouliez ou non, vos outils vont la consulter constamment.
Ils lisent vos specs, vos notes, vos exemples, vos tests, vos conventions de nommage, la structure de votre repo et toutes les autres miettes que vous laissez derrière vous.
C’est aussi pour ça que le TDD commence à sembler beaucoup moins optionnel.
Quand la différence, c’est 5 000 lignes qui règlent un vrai problème contre 100 000 lignes qui ne servent à rien tout en faisant exploser la dette technique, on comprend très vite ce qui compte et pourquoi.
Les modes de défaillance récurrents
Alors, quand les gens lancent des avertissements alarmistes sur le « vibe coding » et l’automatisation par IA à grande échelle, la plupart des plaintes remontent à quelques modes de défaillance très précis :
1. Une documentation médiocre, ou absente. Cela inclut la documentation trop dense ou difficile à analyser.
2. Donner aux agents un accès root aux systèmes de production.
3. Laisser les agents configurer ou gérer la CI/CD sans une surveillance technique stricte.
Rappel : des mots comme « bon » ou « meilleur » ne veulent rien dire en génie logiciel s’ils ne s’appuient pas sur un support technique rigoureux.
Votre poste d’ingénieur logiciel ou d’SRE continuera d’exister dans un avenir prévisible. Mais le rôle est très différent maintenant, et les attentes aussi.
L’automatisation a changé la donne.
De plus en plus, le travail glisse vers le haut : architecture, design du contexte, validation, guidage comportemental, tests, gouvernance et revue.
Aujourd’hui, c’est à vous de gérer les conditions dans lesquelles les systèmes automatisés se comportent bien.
Félicitations pour votre promotion.
Maintenant, il est temps de s’y mettre sérieusement.