Quand la PR paraît propre, mais qu’un truc cloche
Si vous shippez avec l’AI depuis plus de quelques semaines, vous connaissez probablement déjà cette sensation.
Vous ouvrez une pull request. Le code est suffisamment propre. Les noms tiennent la route. Les tests existent. Rien n’a l’air manifestement cassé. Et pourtant, quelque chose sonne faux.
Peut-être que la boundary est un peu floue. Peut-être que le contract est implicite au lieu d’être énoncé. Peut-être que le happy path est couvert, mais que la vraie règle métier vit encore dans la tête de quelqu’un. Vous sentez le risque, même sans pouvoir montrer une ligne catastrophique du doigt.
C’est le nouveau problème du code review.
La plupart des équipes font encore passer le développement assisté par AI dans un vieux flux de travail : écrire un prompt, générer un diff, ouvrir la PR, puis demander à un ingénieur senior d’inspecter le code assez minutieusement pour repérer des invariants cassés, des cas limites manquants, une dérive d’architecture et du risque caché.
Ce modèle avait du sens quand les humains écrivaient eux-mêmes presque toute l’implémentation. Il en a beaucoup moins quand un modèle peut générer l’implémentation, la première suite de tests, le schema et même le squelette des contracts en une seule passe.
À partir de là, le code review ligne par ligne cesse d’être l’endroit le plus rentable où investir l’attention des ingénieurs seniors.
La vraie question n’est plus : “Est-ce que cette fonction a l’air raisonnable ?”
La vraie question devient : “A-t-on défini le bon comportement, la bonne boundary et le bon invariant avant même que cette fonction existe ?”
C’est l’inversion de flux de travail que l’AI provoque. Le code review ne disparaît pas. Mais le centre de gravité remonte en amont. À l’ère de l’AI, le code review devient une revue des spécifications.
Pourquoi ce basculement paraît si différent
Pendant longtemps, la plupart des équipes d’ingénierie ont traité les spécifications comme un simple support.
Le code était la vraie chose. Le doc comment n’était qu’un indice. L’ADR n’apportait du contexte que si quelqu’un avait le temps de la lire. Le schema n’était “que de la validation”. Le fichier Gherkin était un bonus, à condition que quelqu’un prenne la peine de le garder à jour.
Cette hiérarchie est en train de se fissurer.
Si un LLM peut transformer rapidement et de façon répétée une spécification en artefacts d’implémentation, alors la spécification n’est plus secondaire. Elle devient l’artefact source dont dérive le reste du système.
Et ça déplace l’endroit où les erreurs coûtent le moins cher à détecter.
Si la spécification est vague, le modèle peut produire une implémentation magnifiquement structurée de la mauvaise chose. Il peut vous livrer un code propre, des tests plausibles et un faux sentiment de confiance. Même un bon code review peut rater le vrai problème, parce que le bug n’est pas dans la syntaxe. Le bug est dans l’intention.
C’est ce qui rend ce moment à la fois délicat et important. L’AI facilite la production de sorties convaincantes. Elle rend aussi beaucoup plus dangereux le fait d’être approximatif sur ce que vous demandez.
Si la spécification est précise, bien délimitée et testable, tout devient plus simple. L’implémentation devient plus simple. La validation devient plus simple. La revue devient plus simple. Le CI devient plus solide.
Voilà pourquoi la partie la plus utile de la revue humaine s’éloigne de l’audit manuel de chaque branche pour se concentrer sur l’artefact qui définit ce comportement en amont.
Une spécification n’est pas un cahier des charges géant
Quand on entend le mot “spécification”, on imagine souvent un document gonflé à bloc que personne n’a envie d’écrire et auquel plus personne ne croit six semaines plus tard.
Ce n’est pas ça qui compte ici.
Dans un flux de travail assisté par AI et réellement praticable, une spécification est n’importe quel artefact qui définit le comportement attendu avec assez de précision pour permettre la génération et l’enforcement.
Cela peut être :
- une ADR Markdown qui décrit une boundary rule
- un schema Zod qui définit la forme des entrées externes
- une signature de fonction accompagnée d’un doc comment précis
- un scénario Gherkin qui capture le comportement observable
- un bloc de contract avec preconditions et postconditions
- un modèle de reducer ou une table de transition d’état
Aucun de ces artefacts n’a besoin d’être lourd. Ils doivent juste être assez clairs pour que les outils puissent en tirer quelque chose d’utile.
C’est ce seuil qui compte. Une spécification utile n’est pas seulement lisible par des humains. Elle est exploitable par le système qui entoure la codebase.
À quoi commence à ressembler une excellente revue
Dans l’ancien modèle, un ingénieur senior dépense son énergie sur des questions comme :
- cette implémentation est-elle propre ?
- l’auteur a-t-il raté un cas limite ?
- ces tests sont-ils assez solides ?
- cet import enfreint-il une boundary ?
Ces questions comptent encore. Ce ne sont simplement plus les premières questions qui offrent le plus de levier.
Dans un flux de travail orienté spécification, les questions les plus utiles deviennent :
- le contract est-il réellement correct ?
- le schema définit-il la vraie boundary ?
- les règles métier sont-elles complètes ?
- l’ADR est-elle assez précise pour permettre l’enforcement ?
- ces propriétés expriment-elles la vraie sémantique ?
Ce sont de meilleures questions de revue parce qu’une bonne réponse améliore plusieurs artefacts d’un coup.
Si vous resserrez une ADR vague, vous améliorez la règle d’architecture, le guidage d’implémentation et l’enforcement en CI en un seul mouvement.
Si vous corrigez un schema faible, vous améliorez la validation runtime, l’inférence de types et la qualité de génération de code en un seul mouvement.
Si vous affûtez un contract, vous améliorez l’implémentation, les tests et la résistance aux mutations en un seul mouvement.
Voilà la différence de levier. Vous n’inspectez plus les artefacts générés un par un. Vous examinez l’artefact qui leur donne leur forme.
Pourquoi le code review traditionnel commence à craquer
Le code review traditionnel part du principe que les humains sont les auteurs principaux et que la personne qui relit vérifie, à partir du code final, la qualité d’un raisonnement humain.
Avec l’AI, cette hypothèse s’affaiblit chaque semaine.
Un modèle peut produire cinquante lignes plausibles en quelques secondes. Il peut en produire cinquante de plus tout aussi vite. Puis cinquante autres encore. Si tout votre processus dépend d’une personne censée repérer manuellement une dérive sémantique enfouie dans ce flux, la surface de review grandit plus vite que l’attention humaine n’y parviendra jamais.
Cela crée un mauvais équilibre :
- la génération de code accélère
- les diffs deviennent plus gros ou plus fréquents
- la fatigue des relecteurs augmente
- la confiance sémantique baisse
- les équipes compensent avec l’instinct, l’intuition et le “looks good to me”
Ce n’est pas une stratégie pour scaler. C’est du risque accumulé avec un joli formatage.
Le meilleur choix consiste à réduire dès le départ la quantité de revue subjective dont vous avez besoin. Faites passer davantage de sens dans des spécifications déterministes, qu’on peut relire et contrôler. Puis laissez la machine vérifier si le code reste aligné avec ce sens.
Le CI rend cette inversion réelle
Cette inversion du flux de travail ne fonctionne que si la spécification est liée à l’enforcement.
Sinon, vous ne faites que rebaptiser la documentation en espérant que les gens la respecteront davantage.
L’enjeu, c’est de rendre la spécification opérationnelle.
Cela veut dire :
- les décisions d’architecture se compilent en règles de dépendance
- les schemas définissent des boundaries sûres au runtime comme au niveau des types
- les contracts génèrent des checks exécutables
- les listes de propriétés pilotent la génération de tests
- la sémantique critique devient un merge gate
Une fois que c’est en place, le CI cesse d’être un simple système de build passif et devient le mécanisme qui maintient l’implémentation alignée sur l’intention.
C’est aussi pour ça que les living specifications deviennent enfin réalistes pour des équipes normales. Historiquement, la documentation pourrissait parce que personne n’avait le temps de garder le texte et le code synchronisés à la main.
L’AI change l’économie d’écriture et de mise à jour de ces artefacts. Le CI change l’économie de leur enforcement.
Il vous faut les deux. L’AI sans enforcement vous donne une dérive bien polie. L’enforcement sans bonnes specs vous donne une confusion rigide.
Garde-fous stricts, revues humaines
C’est aussi la partie de la philosophie d’Autotomy qui me paraît de plus en plus juste.
L’idée est simple : mettez les règles non négociables dans des garde-fous stricts, puis laissez la revue humaine se concentrer sur les parties qui demandent vraiment du jugement.
Cela veut dire que les types, les schemas, les contracts, les règles de dépendance et les deterministic checks prennent en charge les modes de panne connus. Ils tournent à chaque fois. Ils ne se fatiguent pas. Ils ne se laissent pas distraire par un diff bien présenté. Ils se moquent de savoir si le code vient d’un staff engineer ou d’un modèle de langage.
Ensuite, la couche de revue devient plus resserrée et meilleure.
Au lieu de dépenser l’attention senior sur des choses que le système aurait pu rejeter automatiquement, vous la dépensez sur les arbitrages, la sémantique, les interfaces et l’architecture. Vous vous demandez si la boundary est correcte, si le contract est honnête, si le remplacement satisfait vraiment l’interface, si le système devient plus simple ou plus difficile à faire évoluer.
Cette dernière partie compte énormément.
L’un des effets secondaires les plus sains du travail orienté spécification, c’est qu’il vous pousse vers des points de coupe plus nets. Si un module peut être remplacé tant qu’il satisfait le contract et passe les checks, vous cessez de traiter chaque implémentation comme sacrée. Vous commencez à concevoir pour un remplacement sûr au lieu d’une préservation douloureuse.
C’est un déplacement subtil, mais il change la manière dont les équipes gèrent la croissance. La codebase cesse de ressembler à quelque chose qu’on ne peut réparer qu’avec précaution depuis l’intérieur. Elle commence à ressembler à un système doté de seams explicites.
C’est en réalité une bonne nouvelle pour les ingénieurs seniors
Ce basculement ne rend pas le jugement des ingénieurs seniors moins précieux. Il le rend plus focalisé et plus important.
Un ingénieur senior n’a plus le plus de valeur comme moteur humain de diff syntaxique. Sa vraie valeur se situe là où l’ambiguïté se résout, où les invariants se choisissent, où les interfaces prennent forme et où les arbitrages deviennent explicites.
Cela veut dire davantage de temps passé à :
- rédiger des ADR précises
- définir des contracts et des schemas
- relire des changements sémantiques plutôt que stylistiques
- décider quelles propriétés méritent de l’enforcement
- transformer l’architecture en règles mergéables
C’est un bien meilleur usage d’une attention coûteuse.
La machine excelle à remplir les détails d’implémentation. Les ingénieurs seniors restent bien meilleurs pour décider de ce qui doit rester vrai lorsque le système est mis sous stress, modifié et amené à scale.
Vous n’avez pas besoin d’un gros rewrite de process
Cela peut paraître plus gros que ça ne l’est réellement.
Vous n’avez pas besoin de lancer une initiative de formal methods. Vous n’avez pas besoin d’arrêter de shipper. Vous n’avez pas besoin d’enterrer l’équipe sous le process.
Commencez par un déplacement étroit : traitez une seule classe de spécification comme un artefact de première classe, explicitement soumis à review.
Une séquence pratique ressemble à ceci :
- exiger des doc comments et des schemas précis sur les boundaries critiques
- traiter les changements d’ADR comme des sujets de revue senior
- générer les tests et les contracts à partir de ces artefacts
- appliquer en CI les règles d’architecture et la dérive des contracts
- rétrograder les commentaires de revue purement stylistiques au profit de la revue sémantique
C’est suffisant pour changer la culture.
Une fois que les équipes sentent que de meilleures spécifications réduisent la friction de review en aval, la dynamique commence à s’auto-renforcer. Les revues deviennent plus nettes. Les diffs font moins peur. La confiance remonte.
Le vrai basculement stratégique
Les équipes qui gagnent avec l’AI ne seront pas celles qui se contentent de générer du code plus vite.
Ce seront celles qui déplacent l’attention humaine vers la partie la plus étroite et la plus rentable du flux de travail.
Cette partie, c’est la spécification.
Quand la spécification devient l’artefact principal, le code cesse d’être la seule chose qui mérite une review ligne par ligne. Il devient l’un des outputs d’un système plus discipliné.
Voilà le vrai basculement.
L’implémentation compte encore. Beaucoup. Mais de plus en plus, la décision de revue la plus importante intervient avant même que l’implémentation existe.
Et c’est pour cela qu’à l’ère de l’AI, le code review devient une revue des spécifications.