Comment nous utilisons l'IA pour développer — et ce que nous ne lui confions pas

Il y a deux ans, la question était de savoir si l’IA servait à quelque chose en développement. Aujourd’hui, la question est de savoir où s’arrêter — parce que le coût d’un mauvais usage est devenu réel et qu’il se paie en dette technique.

Voici comment nous avons tranché chez nous, avec la règle qui nous sert de garde-fou.

La règle que nous appliquons

L’IA écrit ce qu’un humain peut vérifier en moins de temps qu’il n’en aurait mis à l’écrire.

Toute la démarcation tient là. Si vérifier coûte aussi cher que produire, le gain est nul et le risque augmente — parce que la vérification finit par être bâclée. Cette règle exclut d’emblée les décisions structurantes, dont le coût de vérification est très élevé et différé dans le temps.

Photo : One Idea LLC — licence CC0.

Les quatre usages qui fonctionnent

Générer du code à partir d’une spécification écrite

Le mot important est écrite. Une demande floue produit un code plausible et faux — c’est le pire résultat possible, parce qu’il passe la revue superficielle.

En pratique : nous décrivons le comportement attendu, les cas limites et les contraintes, puis nous générons. La rédaction de cette description prend du temps, et c’est très bien : elle aurait dû être faite de toute façon, et elle bénéficie aussi au relecteur humain.

Écrire les tests

C’est l’usage où le rapport bénéfice/risque est le meilleur. Générer les cas limites d’une fonction est fastidieux pour un humain et rapide pour un modèle, et le résultat est immédiatement vérifiable : le test passe ou il échoue.

Attention à un piège : ne demandez jamais d’écrire le test après le code en se basant sur le code. Vous obtenez un test qui confirme le comportement existant, bugs compris. Le test doit partir de la spécification, pas de l’implémentation.

Produire la documentation

Documenter une architecture ou une procédure d’installation à partir du code réel donne de bons résultats, à condition de relire. C’est aussi la tâche que les équipes repoussent le plus, donc celle où le gain net est le plus élevé.

La première passe de revue

Avant la revue humaine, une passe automatique repère les oublis mécaniques : cas d’erreur non gérés, valeurs nulles, incohérences de nommage. Cela ne remplace pas la revue — cela libère le relecteur pour ce qui compte vraiment, c’est-à-dire les questions de conception.

Les quatre choses que nous ne lui confions pas

L’architecture. Une décision d’architecture engage des années. Elle repose sur du contexte qui n’est écrit nulle part : ce que sait l’équipe, ce que le client peut exploiter, ce qui a échoué ailleurs. Un modèle produit ici des réponses convaincantes et génériques — la pire combinaison.

La modélisation des données. C’est la décision la moins réversible du projet. Une erreur de modèle se découvre au bout de six mois, quand la base contient des données. Le coût de correction est sans commune mesure avec le temps gagné à la conception.

L’arbitrage de périmètre. Décider ce qui entre dans la première version suppose de connaître les enjeux politiques, les échéances réelles et les rapports de force chez le client. Rien de tout cela ne figure dans une spécification.

La conception de la sécurité. Non par méfiance de principe, mais parce que le coût asymétrique est extrême : une faille coûte incomparablement plus que le temps économisé. Nous nous appuyons sur des composants éprouvés et sur des revues dédiées.

Photo : HD Wallpapers — licence CC0.

Ce que nous avons dû mettre en place

L’IA nous a fait produire plus, donc elle a déplacé le goulot d’étranglement vers la revue. Trois ajustements ont été nécessaires.

Des revues plus courtes et plus fréquentes. Une revue de deux cents lignes est sérieuse. Une revue de deux mille est un tampon. Nous avons réduit la taille des lots, quitte à en avoir davantage.

Une exigence de tests renforcée. Puisque le code arrive plus vite, la seule barrière qui tienne à ce rythme est automatique. Nous n’acceptons pas de code non couvert dans les chemins critiques.

Une règle explicite d’attribution. Le développeur qui soumet du code en est responsable, qu’il l’ait écrit ou généré. Cette règle paraît évidente ; sans elle, une zone grise s’installe très vite.

Photo : domaine public (CC0).

Ce que nous ne laissons pas faire à l’IA

La question de la limite revient systématiquement, et notre réponse tient en trois points.

Les décisions d’architecture. Un modèle produit une proposition plausible et argumentée pour à peu près n’importe quel découpage. Ce qu’il ne peut pas faire, c’est arbitrer en connaissant l’équipe qui maintiendra le système, l’historique du client et ce qui est prévu dans dix-huit mois. C’est précisément ce qui fait la valeur d’une décision d’architecture.

Le code qui touche à la sécurité et aux paiements. Non parce que le résultat serait systématiquement mauvais, mais parce que l’erreur y est coûteuse et difficile à détecter par relecture. Sur ces portions, nous écrivons à la main et nous relisons à deux.

La revue finale. Un modèle relit très bien la forme et repère des défauts réels. Il ne sait pas dire qu’une fonctionnalité ne correspond pas au besoin, parce qu’il ne connaît pas la conversation qui a eu lieu avec l’utilisateur.

L’effet sur la revue de code

C’est le changement le plus net, et il n’était pas prévu.

Quand le code s’écrit plus vite, le volume à relire augmente dans les mêmes proportions. La revue devient le point de passage étroit de la chaîne, et un relecteur devant trois cents lignes générées ne les lit pas de la même manière que trois cents lignes écrites par un collègue.

Deux ajustements que nous avons faits.

Des lots plus petits, imposés. Une modification qui dépasse quelques centaines de lignes est découpée avant d’être proposée. Cette contrainte existait déjà ; elle est devenue non négociable.

L’auteur explique son intention avant la revue. Pas ce que fait le code — cela se lit — mais pourquoi cette approche plutôt qu’une autre. C’est ce qui permet au relecteur de vérifier une décision plutôt que de vérifier une syntaxe.

Autrement dit, l’IA a déplacé notre effort de l’écriture vers la vérification. Le gain net reste réel, il est simplement plus modeste que ce que les temps de génération laissent croire.

Le gain réel, honnêtement

Sur la phase de construction, l’accélération est nette — de l’ordre de 30 à 40 % sur les tâches concernées, avec de grandes variations selon la nature du code. Et comme la construction était le poste le plus long du projet, l’effet se voit sur le calendrier complet : une première version en production demande aujourd’hui un à trois mois, contre trois à six auparavant.

La nuance à porter auprès des clients n’est donc pas que le gain serait faible, mais qu’il est localisé. Le cadrage, le délai de décision et la reprise de données n’ont pas bougé d’un jour : ils occupent désormais la moitié du calendrier, et ce sont eux qui décident de la date.

Autrement dit, son meilleur effet n’est pas seulement d’écrire du code plus vite. C’est de permettre à des ingénieurs de passer plus de temps sur les décisions qui, elles, ne se délèguent pas.