Les idées étaient bonnes. L’économie ne l’était pas.

Le software engineering est rempli d’idées qui paraissent immédiatement justes dès qu’on les lit.

Bien sûr que des contracts devraient définir ce qu’une fonction peut accepter et renvoyer. Bien sûr que des tests devraient vérifier des properties plutôt que quelques exemples choisis à la main. Bien sûr qu’une équipe devrait mesurer si les tests détectent réellement des fautes au lieu de supposer que la coverage suffit. Bien sûr que les décisions d’architecture devraient rester synchronisées avec le code qu’elles gouvernent.

Rien de tout cela n’était vraiment controversé. Le problème était économique. Ces stratégies coûtaient cher exactement dans la ressource que la plupart des équipes ne pouvaient pas multiplier: l’attention spécialisée.

Pendant des années, ces pratiques ont suivi le même cycle. Une équipe en adoptait une. La qualité montait. Puis le coût de maintenance arrivait. Les contracts dérivaient. Les property tests ne suivaient plus les changements de schema. Les surviving mutants s’empilaient sans triage. La documentation d’architecture devenait fiction. La méthode n’échouait pas parce qu’elle était fausse. Elle échouait parce qu’elle exigeait un niveau d’expertise continu que peu d’équipes produit pouvaient soutenir.

Voilà le vrai contexte du moment AI. Le changement important n’est pas seulement que les modèles écrivent du code plus vite. Le changement important est qu’ils peuvent désormais absorber une grande partie du travail de spécification et de vérification qui rendait ces pratiques trop coûteuses.

Ce qui maintenait réellement ces stratégies dans la niche

Ce n’était jamais seulement une question de compute. Le compute bon marché existe depuis longtemps.

Ce n’était pas non plus uniquement un problème de tooling. Beaucoup d’outils existaient déjà. Mais il fallait toujours quelqu’un capable de formuler les bons invariants, les bons generators, les bons contracts et les bonnes boundary rules.

Le vrai bottleneck, c’était une expertise difficile à paralléliser.

  • Design by contract demandait des engineers capables d’écrire et de maintenir des preconditions, postconditions et invariants utiles dans la durée.
  • Property-based testing demandait des personnes capables de penser en round trips, idempotence, comportement d’erreur et properties algébriques plutôt qu’en simples exemples.
  • Mutation testing demandait une triage des survivors pour distinguer les vraies lacunes des equivalent mutants.
  • Type-level correctness demandait une réelle maîtrise des branded types, phantom types, typestates ou d’outils de vérification formelle.
  • Living specifications demandaient de traduire en continu des décisions humaines en règles d’architecture exécutables.

Chaque stratégie avait sa propre taxe de maintenance. Les combiner coûtait encore plus cher, parce qu’il fallait aussi produire le glue entre elles.

Voilà pourquoi tant d’idées “good on paper” sont restées cantonnées à l’aerospace, à la finance, à la recherche en formal methods ou à des équipes d’infrastructure exceptionnellement disciplinées. Les méthodes fonctionnaient. Le modèle de staffing, non.

Ce que change l’AI

L’AI ne supprime pas le engineering judgment. Elle change l’endroit où on le dépense.

Avant, un senior engineer devait rédiger presque tout le scaffolding à la main. Aujourd’hui, le modèle peut proposer un premier contract, suggérer des properties, produire un schema, transformer une décision en architecture rule et même rédiger un premier regression test pour un surviving mutant. L’humain revoit la correction métier au lieu de commencer depuis une page blanche.

Le changement est plus important qu’il n’en a l’air.

L’ancien workflow était author-heavy. Le nouveau devient review-heavy.

Cela veut dire:

  • les contracts deviennent moins chers à introduire
  • les property tests deviennent plus accessibles
  • le mutation testing devient plus exploitable
  • les architecture constraints deviennent plus faciles à faire respecter

Le véritable unlock économique est là. Il ne s’agit pas de remplacer les engineers par un modèle. Il s’agit de rendre abordables des stratégies qui exigeaient auparavant une autorité experte continue.

L’idée essentielle: ces stratégies se renforcent entre elles

La partie la plus intéressante n’est pas une technique isolée.

Ce qui change vraiment, c’est que l’AI rend le stack abordable comme système.

Un contract peut nourrir un property test. Un property test peut être évalué par mutation testing. Un schema peut définir la runtime boundary. Une ADR peut devenir une architecture rule. Un branded type peut réduire la surface avant même qu’un check runtime ne s’exécute. La valeur n’est pas seulement dans chaque partie. Elle est dans le glue entre les parties.

Avant l’AI, la plupart des équipes pouvaient au mieux justifier une seule de ces stratégies. Maintenant, elles peuvent en combiner plusieurs sans transformer la reliability en programme réservé aux spécialistes.

Ce n’est pas de la magie

Il existe malgré tout une mauvaise manière de faire.

Si vous laissez l’AI générer du code, des contracts et des tests sans enforcement déterministe, vous ne produisez qu’un plus gros tas de texte plausible. Le but n’est pas de demander au modèle de bénir le codebase. Le but est d’utiliser le modèle pour produire des artefacts qui peuvent être vérifiés à faible coût et de manière répétée.

Le bon pattern reste donc le pattern ennuyeux:

  • générer avec AI
  • valider avec des outils déterministes
  • reviewer les changements au niveau de la spécification
  • faire échouer CI immédiatement lorsqu’une règle est violée

L’AI est utile ici parce qu’elle réduit l’écart d’expertise, pas parce qu’elle doit devenir l’arbitre final.

Pourquoi cela compte maintenant

Les équipes utilisent déjà l’AI pour compresser le temps d’implémentation. Le risque, c’est que la vitesse de livraison augmente plus vite que la profondeur de vérification.

Dans ce cas, on n’obtient pas une organisation d’ingénierie plus productive. On obtient un chemin plus rapide vers des systèmes fragiles.

L’opportunité consiste à utiliser les mêmes modèles qui accélèrent la génération pour ressusciter des pratiques de reliability historiquement trop coûteuses. C’est ainsi qu’on empêche la vitesse de se transformer en dette opérationnelle.

Les prochaines années favoriseront les équipes qui comprendront cette différence tôt. AI-assisted coding seul n’est pas une stratégie. AI-assisted verification and enforcement en est une.

Et c’est pour cela que tant d’anciennes idées d’ingénierie redeviennent importantes: non parce qu’elles seraient soudainement plus justes, mais parce qu’elles deviennent enfin économiquement praticables.