Le ticket semblait simple : ajouter un export CSV dans une application métier. L’assistant a proposé la fonction, les tests et la documentation en quelques minutes. Puis les questions arrivent : qui peut exporter quelles données ? Que devient le serveur si le fichier contient un million de lignes ? Une cellule peut-elle déclencher une formule dangereuse dans un tableur ? Le code est écrit, mais le travail n’est pas terminé. Voilà le déplacement que les assistants de programmation rendent incontournable : produire devient plus facile ; prouver que la production mérite confiance reste difficile.
Du code instantané, pas du logiciel instantané
Depuis le lancement de GitHub Copilot, puis la diffusion des assistants conversationnels et des environnements de développement intégrant des modèles génératifs, l’aide au programmeur a changé d’échelle. Elle ne se limite plus à compléter une ligne : elle propose une fonction, explique un dépôt, esquisse une migration ou suggère un correctif. La trajectoire est connue ; son prolongement vers septembre 2026 doit néanmoins être traité comme une perspective, pas comme une mesure acquise de productivité.
Les premiers travaux sur ces outils ont montré des accélérations sur certaines tâches délimitées. Mais terminer plus vite un exercice ne signifie pas livrer plus vite une fonctionnalité fiable dans un système ancien. Dans une entreprise, le développement comprend aussi la compréhension du besoin, les discussions d’architecture, les validations et les incidents. Le temps de frappe n’est qu’une fraction du coût du logiciel. C’est précisément cette fraction que l’IA réduit le plus visiblement.
Le piège consiste donc à compter les lignes acceptées ou les propositions utilisées. Ces indicateurs décrivent l’activité de l’assistant, pas nécessairement la valeur obtenue. Une modification volumineuse peut augmenter la charge collective si trois collègues doivent ensuite la comprendre, la corriger et l’exploiter.
Les tests deviennent le premier poste de contrôle
Un assistant sait produire des tests plausibles. Cela aide à couvrir des cas répétitifs ou à démarrer dans un projet mal équipé. Mais il peut aussi écrire des tests qui confirment exactement son erreur : la fonction et sa vérification reposent alors sur la même mauvaise interprétation. Un voyant vert prouve seulement que le programme respecte les assertions exécutées, pas que ces assertions correspondent au besoin.
Reprenons l’export CSV, exemple fictif mais banal. Tester qu’un fichier contient les colonnes attendues ne suffit pas. Il faut vérifier les droits d’accès, les caractères spéciaux, les volumes importants et les données susceptibles d’être interprétées comme des formules. Ces situations viennent du contexte métier et des menaces possibles, pas uniquement de la lecture de la fonction.
Une méthode robuste consiste à définir les critères d’acceptation avant de demander l’implémentation. Les équipes peuvent ensuite combiner tests unitaires, tests d’intégration et vérifications de propriétés : un utilisateur ne doit jamais obtenir les données d’un autre, par exemple. Les tests de mutation, qui introduisent volontairement de petites erreurs, permettent également d’évaluer si la suite détecte réellement des défauts.
La revue humaine devient une ressource rare
Quand proposer une modification coûte moins cher, davantage de modifications peuvent arriver en revue. Le goulot d’étranglement se déplace vers les personnes capables de juger leur pertinence. Et lire du code inconnu demande une attention que la vitesse de génération ne raccourcit pas mécaniquement.
Le risque est renforcé par la présentation : un code propre, bien nommé et abondamment commenté inspire confiance. Pourtant, une règle d’autorisation oubliée peut se cacher dans une implémentation élégante. La revue doit donc porter sur les hypothèses autant que sur la syntaxe. D’où viennent les données ? Quelles garanties apporte réellement cette bibliothèque ? Que se passe-t-il après un échec partiel ?
Les petites contributions gardent ici un avantage décisif. Demander à l’assistant une modification limitée, accompagnée de ses hypothèses et des vérifications effectuées, facilite le contrôle. À l’inverse, accepter une refonte massive parce qu’elle arrive instantanément transforme un gain local en dette de compréhension. L’auteur humain doit rester capable d’expliquer et d’assumer le changement.
Sécurité : le plausible n’est pas une preuve
Les risques ne sont pas théoriquement nouveaux : injections, secrets exposés, dépendances vulnérables et contrôles d’accès défaillants existaient avant les modèles génératifs. Des recherches ont toutefois montré que les suggestions d’assistants pouvaient contenir des failles. L’IA ne remplace donc ni l’analyse statique, ni la recherche de secrets, ni l’examen des dépendances.
Elle ajoute aussi des pièges spécifiques. Un modèle peut recommander un paquet inexistant ou confondre des interfaces de programmation. Des travaux ont documenté les hallucinations de noms de paquets, susceptibles d’être exploitées si un tiers publie ensuite une dépendance portant ce nom. La réponse pratique consiste à vérifier l’existence, la provenance et la nécessité de chaque composant ajouté.
Avec des assistants capables d’agir sur un dépôt, la frontière de confiance devient également centrale. Un fichier ou une documentation externe peuvent contenir des instructions malveillantes destinées à détourner l’outil. Limiter ses permissions, isoler l’exécution et exiger une validation pour les opérations sensibles restent des garde-fous essentiels. Leur importance devrait croître si l’autonomie des assistants progresse.
La maintenance révèle la facture différée
Un correctif peut fonctionner aujourd’hui et coûter cher demain. L’assistant a-t-il repris les conventions du projet ou créé une nouvelle abstraction inutile ? A-t-il ajouté une bibliothèque pour quelques lignes économisées ? Le comportement reste-t-il observable en production ? Ces questions déterminent la facilité du prochain changement.
Dans un patrimoine logiciel ancien, l’enjeu n’est souvent pas d’inventer une solution, mais de respecter des contraintes invisibles : formats historiques, clients particuliers, traitements nocturnes. L’IA peut aider à explorer ce terrain, sans garantir qu’elle l’a compris. Les tests de caractérisation, qui capturent le comportement existant avant modification, prennent alors une valeur particulière.
Mesurer le gain au bon endroit
Pour évaluer un assistant, mieux vaut comparer des tâches similaires et suivre leurs suites que célébrer une démonstration spectaculaire. Une expérimentation utile observe plusieurs dimensions :
- Le délai complet, du besoin clarifié à la mise en production.
- Le temps consacré à la revue, aux corrections et aux tests supplémentaires.
- Les défauts découverts après livraison et leur gravité.
- La facilité avec laquelle une autre personne reprend le code.
Il faut aussi distinguer les usages. Générer un script jetable, compléter une interface interne et modifier un mécanisme de paiement n’appellent pas le même niveau de contrôle. Le bénéfice dépend de la tâche, de l’expérience du développeur et de la qualité des garde-fous disponibles.
Et maintenant ? À l’horizon de septembre 2026, l’hypothèse la plus solide n’est pas la disparition de la vérification, mais sa montée en valeur. Les équipes qui pourraient tirer le meilleur parti des assistants seront celles qui savent spécifier, tester et limiter les changements. Le véritable progrès ne sera pas d’obtenir davantage de code : ce sera de livrer plus de fonctions utiles sans rendre leur fiabilité et leur entretien plus coûteux.
