Le dernier dactylo : pour un développement logiciel intégré

La frappe n’a jamais été le vrai travail du génie logiciel.

L’ancien artisanat

Autrefois, le logiciel était lent. Il était lent parce que les gens étaient lents. Les gens étaient la seule machinerie dont nous disposions pour le produire.

Une idée allait à un analyste. L’analyste rédigeait une exigence. L’exigence allait à un architecte. L’architecte dessinait des boîtes. Les boîtes allaient aux développeurs. Les développeurs tapaient. Les relecteurs lisaient. Les testeurs testaient. La sécurité regardait en dernier. La conformité, plus tard encore. Chaque passage de relais faisait perdre quelque chose. Le sens fuyait à chaque jointure.

Nous appelions cela un processus. C’était une course de relais disputée dans le brouillard, sur des pistes mal tracées.

Les coûts suivaient cette forme. L’écriture du code représentait peut-être un tiers de l’effort. Le reste, c’était de l’attente, des explications, des reprises et des réparations. Un défaut découvert en production coûtait plusieurs fois ce qu’il aurait coûté sur le poste du développeur. Tout le monde le savait. Nous avons bâti des cérémonies autour de ce problème pour y remédier. Stand-ups. Sprints. Points de contrôle. Elles ont aidé. Elles n’ont pas changé la physique. Les humains tapaient. Les humains vérifiaient. Les humains laissaient passer des choses.

L’erreur

Puis les machines sont arrivées. Elles savaient écrire du code. Vite. Avec aisance. Sans relâche.

Nous avons donc fait la chose évidente. Nous les avons confiées à l’ancien processus. Un copilote pour chaque développeur. Un chatbot dans la file des tickets. Un dactylo plus rapide au même bureau.

Cela ressemblait à un progrès. Souvent, ce n’en était pas un. Une étude contrôlée menée en 2025 a montré que des développeurs expérimentés étaient plus lents avec une aide IA ponctuelle sur des bases de code matures. Le code arrivait plus vite. La relecture, la correction et le doute arrivaient plus lentement. Le goulot d’étranglement s’est déplacé. Personne ne s’est déplacé avec lui.

Voilà le schéma. Un moteur neuf boulonné sur une vieille calèche. C’est la calèche qui impose la vitesse. Les roues n’ont jamais été conçues pour davantage.

L’ancien processus partait du principe que le code était rare et difficile à produire. Il rationnait donc le code. Le code est désormais abondant, et cette abondance brise chacun des anciens processus. Les revues sont submergées. Les suites de tests pourrissent. L’architecture dérive, un correctif plausible après l’autre. Ajoutez l’IA à ce processus et vous obtenez davantage de tout, y compris d’erreurs, livré plus vite.

Ou vous n’obtenez rien. L’équipe apprend à se méfier du résultat et le retape à la main. La puissance est là. Elle n’est simplement jamais allumée.

Le nouveau processus

Partez d’une autre question. Non pas : comment aider les développeurs à taper plus vite ? Mais : qu’est-ce que le logiciel, et que faut-il pour le produire avec une haute qualité ?

Le logiciel est une décision rendue précise. C’est du savoir métier, compressé en règles qu’une machine peut suivre. Le code est la dernière étape. Le savoir est la première. Si le savoir est faux, un code parfait est parfaitement faux.

Le nouveau processus commence donc là. Une personne qui connaît réellement le domaine énonce l’intention. Les contraintes. Les invariants. Ce qui ne doit jamais arriver. Ce que la loi exige. Ce que l’utilisateur redoute. C’est la vraie source. Tout le reste en découle.

Puis des agents travaillent en chaîne, chacun avec une seule tâche.

• Analyse : transforme l’intention en spécification précise et traque les lacunes et les contradictions.
• Conception : propose l’architecture et en consigne les raisons.
• Codage : écrit l’implémentation conformément à la spécification.
• Vérification : contrôle le code par rapport à la spécification, par preuve ou par propriété quand c’est possible, par lecture sinon.
• Tests : écrit les tests à partir de la spécification, et non du code, afin que les deux ne puissent pas partager une même erreur.
• Sécurité, confidentialité, conformité : vérifient chaque modification au regard des politiques, au moment où elle est faite.
• Expert humain : examine ce qui compte. Les décisions. Les compromis. Les surprises.

Les mots clés sont dès la conception. La sécurité n’est pas une phase finale. C’est une contrainte inscrite dans la spécification. La confidentialité est une propriété vérifiée à chaque commit. La conformité est une cartographie vivante qui relie la réglementation aux tests. Les tests naissent avec l’exigence, pas après le code. Chaque contrôle est désormais bon marché, donc chacun s’exécute en permanence. Ce qui était audité chaque trimestre est vérifié en continu.

Chaque affirmation laisse une trace. De l’exigence à la conception, au code, au test, à la preuve. Un auditeur peut la parcourir. Un ingénieur aussi, à minuit.

Ce n’est pas un meilleur outil. C’est une autre usine. C’est ce que le moment exige.

Les chiffres

Une estimation : un pipeline intégré bien mené réduit l’effort humain de 60 à 75 % et le coût total de 50 à 70 %. Les délais calendaires baissent davantage encore. Les défauts qui atteignent la production diminuent de moitié, voire plus.

Mesure (indice, classique = 100)	Processus classique	Processus agentique intégré	Pourquoi
Effort humain	100	25–40	Le codage, l’écriture des tests, la documentation et les reprises passent aux agents
Coût total, y compris l’usage des modèles et l’outillage	100	30–50	L’inférence est bon marché face aux salaires ; le temps des experts demeure
Délai calendaire jusqu’à la mise en production	100	15–35	Agents en parallèle, aucune attente entre les passages de relais
Défauts parvenant en production	100	20–50	Tests issus de la spécification, vérification continue
Corrections de sécurité et de conformité découvertes tardivement	100	10–30	Vérifiées à chaque modification, pas à la fin
Part de l’effort humain consacrée au domaine et à la spécification (%)	environ 25	environ 60	Le travail passe de la frappe à l’intention et au jugement

Ce sont des estimations éclairées, pas des mesures. Elles supposent un système de taille moyenne, un domaine bien compris et un apport solide d’experts. Le coût baisse moins que l’effort, car les modèles, l’outillage et les experts rares restent à payer. Les économies se trouvent dans le codage, les tests, la documentation, les reprises et les corrections tardives. Elles ne se trouvent pas dans la compréhension du problème. Ce coût demeure. Il devient le coût principal.

Ce qui reste

Le dactylo s’en va. Tant mieux. Le dactylo n’a jamais été l’essentiel.

Ce qui reste, c’est la personne qui sait. Le clinicien qui comprend le service. L’ingénieur qui sait comment un système tombe en panne. Le juriste qui sait ce que coûte une clause. Ils écriront moins de code et décideront davantage. Leurs erreurs pèseront plus lourd, car la machine les construira fidèlement.

La discipline change donc. Moins d’art de la syntaxe. Plus d’art de l’intention. Moins d’héroïsme. Plus de preuves.

L’ancien processus échoue si on lui ajoute l’IA. Le nouveau échoue si on en retire le savoir. Le logiciel a toujours été de la pensée rendue solide. Nous sommes enfin libres de travailler sur la réflexion.