La question ne nous est plus posée sous la forme « faut-il y aller ? » mais « comment l’encadrer ? ». En deux ans, les assistants de code sont passés du gadget de démonstration à l’outil que la moitié de nos développeurs ouvre chaque matin. Voici ce que nous en retenons après les avoir utilisés sur de vraies bases de code métier — celles qui ont dix ou quinze ans, des conventions maison, et une recette contractuelle à la fin.
Ce qu’ils accélèrent réellement
Le gain est net, mais il n’est pas là où les démonstrations le placent. Écrire une fonction inédite à partir d’une page blanche n’a jamais été le goulot d’étranglement d’un projet métier. Ce qui coûte du temps, c’est tout ce qui l’entoure — et c’est précisément là que l’outil aide.
- Comprendre un code inconnu lors d’une reprise ou d’un audit : faire expliquer un traitement de 800 lignes va plus vite que le lire.
- Le code répétitif mais non trivial : couches d’accès aux données, mapping d’objets, sérialisation, conversions de formats.
- Écrire les tests, en particulier les cas limites qu’un développeur pressé aurait laissés de côté.
- La migration mécanique d’un framework ou d’une version de langage à une autre, quand la transformation est régulière.
- La documentation, cette tâche que personne ne fait spontanément et dont l’absence coûte cher trois ans plus tard.
Ce qu’ils ne remplacent pas
Un assistant produit du code plausible. Sur un périmètre métier, « plausible » et « correct » sont deux choses différentes, et l’écart se paie en production.
La connaissance du métier
Aucun modèle ne sait que dans votre entreprise, une commande annulée après facturation suit un circuit comptable particulier, ou que ce champ apparemment libre est en réalité contraint par une obligation réglementaire. Ces règles ne sont pas dans le code : elles sont dans la tête de trois personnes. Les faire émerger reste un travail d’analyse, mené avec vos équipes.
L’architecture
Un assistant optimise localement. Il produira volontiers cinq implémentations légèrement différentes du même besoin dans cinq fichiers, chacune défendable isolément. Décider où se situe une responsabilité, ce qui doit être partagé et ce qui doit rester séparé, reste une décision humaine — et c’est celle dont on hérite pendant dix ans.
La revue de code
C’est le point sur lequel nous sommes les plus fermes. Le code assisté augmente le volume produit par développeur, donc le volume à relire. Une équipe qui accélère la production sans renforcer la revue ne gagne pas du temps : elle en emprunte, avec intérêts.
Le cadre que nous posons avant de déployer
Nous n’interdisons pas ces outils et nous ne les imposons pas. Nous exigeons en revanche quatre garde-fous, que nous recommandons à nos clients d’appliquer chez eux.
- Confidentialité d’abord. Le code d’un client ne quitte pas le périmètre autorisé par son contrat. Cela se vérifie dans les conditions du fournisseur, pas dans un billet de blog — y compris celui-ci.
- Aucun code non relu en production. La provenance ne change rien à la règle : elle la rend plus nécessaire.
- Les tests restent écrits en connaissance du besoin. Faire générer un test à partir du code que l’on veut valider produit un test qui confirme le bug.
- Traçabilité des dépendances. Un assistant suggère volontiers une bibliothèque tierce. L’ajout d’une dépendance reste une décision d’architecture, avec ses implications de licence et de maintenance.
Ce que nous en concluons
Les assistants de code apportent un gain de productivité réel et mesurable sur une partie du travail d’un développeur. Ils ne réduisent pas le besoin d’ingénierie : ils le déplacent vers l’amont — comprendre le besoin, décider de l’architecture — et vers l’aval : relire, tester, mettre en production sereinement.
Autrement dit, ils rendent les bonnes équipes plus rapides et les équipes mal encadrées plus rapidement endettées. Une raison de plus de s’intéresser à la méthode avant de s’intéresser à l’outil.
Cet article reflète notre pratique interne à la date de publication. Le sujet évolue vite : si vous vous posez la question pour vos propres équipes, parlons-en directement plutôt que de vous fier à un texte de l’an dernier.