Les limites du code généré par l’IA dans les projets logiciels

Le code généré par l’IA semble abouti, mais recèle des risques en matière de qualité, de sécurité et de maintenabilité

L’IA a transformé le développement logiciel plus rapidement que ne l’avaient prévu la plupart des entreprises. Les équipes peuvent désormais produire du code fonctionnel en quelques minutes au lieu de plusieurs heures. C’est là un véritable avantage. Mais la rapidité n’a de valeur que si le résultat est correct. Si un système est mis en production plus rapidement alors qu’il comporte des défauts cachés, l’entreprise n’a fait qu’accélérer l’apparition de problèmes futurs.

L’un des principaux défis liés à code généré par l’IA est qu’il semble généralement complet. La mise en forme est soignée. Les fonctions sont bien organisées. Les noms de variables sont souvent pertinents. Les tests unitaires peuvent même s’avérer concluants. Cela inspire la confiance avant même que celle-ci n’ait été méritée. La qualité d’un logiciel dépend de la justesse de la logique métier, de la sécurité, de l’évolutivité, de la fiabilité opérationnelle et de la maintenabilité à long terme. L’IA peut apporter son aide dans tous ces domaines, mais elle ne peut pas les garantir.

Les équipes de développement proposaient régulièrement des solutions qui semblaient achevées à environ 80 %. Celles-ci fonctionnaient correctement lors des démonstrations et des revues de code, mais présentaient des défaillances lorsqu’elles étaient soumises à des conditions de production ou à des tests plus complets. Ces 20 % restants mobilisaient un temps de développement disproportionné, car les problèmes restants concernaient la logique, l’architecture et la fiabilité, plutôt que la syntaxe ou la mise en forme.

La raison est simple. Les grands modèles linguistiques génèrent du code à partir de schémas appris lors de leur entraînement. Ils ne disposent d’aucune expérience opérationnelle concernant votre entreprise, votre infrastructure ou les décisions prises par vos équipes d’ingénieurs au fil des années. À moins que ces détails ne soient explicitement fournis, le modèle comble ces lacunes en s’appuyant sur des prévisions statistiques plutôt que sur une connaissance de votre organisation.

Cela pose un défi en matière de gestion. Les indicateurs de productivité peuvent s’améliorer tandis que la qualité des logiciels se détériore insidieusement. Les équipes peuvent faire état d’un plus grand nombre de « stories » terminées, d’un volume de commits plus élevé et de délais de mise en œuvre plus courts, mais la dette technique continue de s’accumuler derrière ces chiffres. Si les dirigeants se concentrent uniquement sur la vélocité de développement, ils risquent de ne pas percevoir les premiers signes avant-coureurs avant que les défauts ne commencent à affecter les clients ou les opérations de l’entreprise.

Le marché prend déjà conscience de ce fossé. Selon l’enquête menée par Stack Overflow auprès des développeurs, la méfiance à l’égard de la précision du code généré par l’IA est passée de 31 % à 46 % en l’espace d’un an. Parmi les développeurs les plus expérimentés, seuls 2,6 % ont déclaré faire pleinement confiance au code généré par l’IA. Cela ne signifie pas pour autant que les ingénieurs expérimentés rejettent l’IA. Cela signifie qu’ils comprennent que l’IA est un accélérateur.

Les organisations qui créent de la valeur durable ne limitent pas l’adoption de l’IA. Elles renforcent le processus de vérification qui l’entoure. Elles attendent des développeurs qu’ils comprennent chaque ligne de code qu’ils valident, qu’elle ait été écrite par un humain ou par un système d’IA. Cette évolution transforme l’IA, qui passe d’une source de risque caché à un multiplicateur de force pour les équipes d’ingénierie.

Le « biais d’automatisation » conduit les développeurs à accorder une confiance excessive au code généré par l’IA et à l’intégrer prématurément

Le prochain défi est davantage d’ordre psychologique que technique. Les êtres humains ont naturellement tendance à faire confiance aux systèmes qui produisent systématiquement des résultats convaincants. Les assistants de programmation basés sur l’IA sont désormais très performants pour générer du code qui semble correct. Cette apparence modifie le comportement des développeurs.

C’est ce qu’on appelle le « biais d’automatisation ». Les gens ont tendance à accepter les recommandations des systèmes automatisés avec moins de discernement qu’ils n’en feraient preuve face à un travail entièrement réalisé par une autre personne. Dans le domaine du développement logiciel, cela signifie que le code est souvent examiné avec moins d’esprit critique, simplement parce qu’il semble professionnel et qu’il suit des schémas familiers.

C’est là que de nombreuses organisations commencent à rencontrer des difficultés. Les ingénieurs ne consacrent plus la majeure partie de leur temps à écrire du code. Ils passent de plus en plus de temps à vérifier les résultats générés par l’IA. Or, cette vérification exige un état d’esprit différent. L’objectif n’est pas de s’assurer que le code semble plausible, mais de prouver qu’il est correct aussi bien dans des conditions normales que dans des situations imprévues.

Le taux de rotation du code mesure la proportion de code récemment validé qui doit être modifié peu après sa fusion. Une augmentation de ce taux indique généralement que les équipes valident le travail avant de l’avoir entièrement vérifié. Les développeurs pensent avoir terminé la tâche, mais doivent y revenir quelques jours ou semaines plus tard, car des problèmes cachés apparaissent lors des tests d’intégration ou de production.

Les chiffres confirment cette tendance. Le taux de modification du code est passé de 3,1 % en 2020 à 5,7 % en 2024, ce qui représente une augmentation relative de 84 % sur une période qui coïncide avec une adoption généralisée de l’IA. Le rapport « State of AI vs. Human Code Generation » de CodeRabbit, basé sur 470 pull requests réelles, a révélé que les pull requests générées par l’IA comportaient en moyenne 10,83 problèmes, contre 6,45 pour le code rédigé par des humains. Les pull requests générées par l’IA contenaient également 1,4 fois plus de problèmes critiques et 1,7 fois plus de problèmes majeurs.

Ces résultats méritent votre attention, car ils mettent en évidence des problèmes dont la résolution est coûteuse. Bon nombre de ces défauts ne sont pas de simples erreurs de mise en forme ou des points-virgules manquants. Ils concernent la logique métier, les choix architecturaux et les failles de sécurité. Ces catégories nécessitent généralement une analyse plus approfondie, des tests plus complets et un effort d’ingénierie accru après le déploiement.

Pour les dirigeants, cela modifie la manière dont la productivité des équipes d’ingénierie doit être mesurée. Un nombre plus élevé de « pull requests » ne se traduit pas automatiquement par une valeur ajoutée accrue pour le client. Un volume de code plus important ne garantit pas un logiciel de meilleure qualité. Des indicateurs tels que les taux de défauts après fusion, le taux de renouvellement du code, les incidents en production et l’efficacité des revues gagnent en importance à mesure que l’adoption de l’IA se généralise.

Les organisations devraient également réexaminer la manière dont les revues de code sont menées. Les réviseurs doivent disposer de suffisamment de temps et d’autorité pour remettre en question les implémentations générées par l’IA, même lorsqu’elles semblent abouties. Les tests indépendants, la validation de la sécurité et la révision architecturale gagnent en importance, car l’IA peut générer des solutions convaincantes qui comportent néanmoins des failles importantes.

Les entreprises qui tireront le plus grand profit de l’IA ne seront pas celles qui intègrent le code le plus rapidement. Ce seront celles qui mettront en place des processus de révision rigoureux, capables d’associer la rapidité de l’IA à une vérification tout aussi rigoureuse. Cette combinaison permet aux organisations de réaliser des gains de productivité sans s’exposer à des risques opérationnels inutiles.

L’IA peine à conserver et à appliquer le contexte architectural à grande échelle, ce qui entraîne des doublons de code et une conception incohérente

L’IA donne les meilleurs résultats lorsque le problème est clairement défini et que la quantité d’informations qu’elle doit traiter est limitée. Les modèles linguistiques modernes sont capables de comprendre des volumes importants de code, mais chaque modèle présente des limites pratiques quant à la quantité de contexte qu’il peut exploiter de manière cohérente. Les grands systèmes d’entreprise dépassent presque toujours ces limites.

La plupart des organisations ont accumulé au fil des années des décisions architecturales, des normes de codage, des utilitaires partagés, des conventions de nommage et des modèles de conception. Une grande partie de ce savoir n’est pas documentée ou n’existe que dans le cadre de discussions internes et de l’expérience des ingénieurs. L’IA ne peut pas déduire ces décisions de manière fiable, à moins qu’elles ne soient explicitement incluses dans la consigne ou mises à disposition via des outils d’aide.

À mesure que les projets prennent de l’ampleur, le contexte revêt une importance croissante. Un développeur comprend qu’il convient de réutiliser une utilitaire existante, car il a déjà travaillé avec le système ou en a appris les conventions. Un modèle d’IA, en revanche, risque de ne pas détecter cette utilitaire si celle-ci ne s’inscrit pas dans le contexte dont il dispose. Il génère alors une nouvelle implémentation qui semble correcte, mais qui fait double emploi avec des fonctionnalités existantes.

Au fil du temps, cela engendre une complexité inutile. De multiples versions d’utilitaires similaires commencent à apparaître dans l’ensemble du code. Sans s’en rendre compte, différentes équipes résolvent le même problème de différentes manières. La maintenance devient plus difficile, car les modifications doivent être appliquées à plusieurs endroits au lieu d’un seul. Le résultat immédiat peut sembler productif, mais le coût à long terme ne cesse d’augmenter.

En général, l’IA ne remet pas en question les informations manquantes. Un nouvel ingénieur qui ne parvient pas à trouver une bibliothèque interne demandera souvent conseil à un collègue. L’IA ne pose pas de questions à moins qu’on ne lui demande de le faire. Elle comble les lacunes en matière d’informations à l’aide de prédictions basées sur ses données d’apprentissage. Ce comportement est utile pour générer du code rapidement, mais il peut aboutir à des solutions qui s’écartent des pratiques d’ingénierie établies.

Pour les dirigeants, il s’agit avant tout d’une question de gouvernance. Les organisations ne doivent pas partir du principe que l’IA comprend l’architecture interne simplement parce qu’elle a accès à une partie du référentiel. L’architecture doit devenir plus accessible grâce à la documentation, aux comptes rendus des décisions architecturales, aux normes de codage et aux processus de développement qui fournissent le contexte approprié aux systèmes d’IA.

Cela représente également une opportunité. Les entreprises qui investissent dans des connaissances techniques structurées tireront davantage parti de l’IA que celles qui s’appuient principalement sur l’expérience individuelle des développeurs. Des systèmes bien documentés sont plus faciles à comprendre pour les utilisateurs et nettement plus simples à prendre en charge de manière cohérente par l’IA.

L’objectif n’est pas d’éliminer le code généré par l’IA. L’objectif est de veiller à ce que le nouveau code renforce l’architecture existante au lieu de la fragmenter progressivement.

Le code généré par l’IA peut, par inadvertance, contourner des contrôles architecturaux et de sécurité essentiels

Les failles de sécurité causées par l’IA sont souvent difficiles à détecter, car le code généré fonctionne généralement comme prévu. L’application s’exécute, la fonctionnalité fonctionne et les tests automatisés peuvent s’avérer concluants. Cela inspire confiance, même lorsque des contrôles essentiels ont été omis.

Les modèles linguistiques génèrent des solutions statistiquement plausibles. Lorsque les contraintes architecturales, les exigences de conformité ou les politiques de sécurité ne sont pas mentionnées dans la consigne, le modèle a souvent tendance à se rabattre sur des modèles de mise en œuvre courants plutôt que sur les normes propres à l’entreprise.

Pour les équipes de direction, cette distinction est importante. De nos jours, la sécurité va bien au-delà de la simple identification des vulnérabilités logicielles. Elle consiste notamment à s’assurer que les applications respectent systématiquement les exigences d’authentification, les règles d’autorisation, les politiques de chiffrement, les normes de journalisation, les procédures de traitement des données et les obligations réglementaires. L’IA ne peut garantir le respect de ces éléments de manière fiable que s’ils sont explicitement intégrés au processus de développement.

Les organisations devraient considérer la validation de la sécurité comme une activité à part entière, plutôt que de partir du principe que le code généré par l’IA a déjà pris en compte ces aspects. Les revues de sécurité, les analyses automatisées, l’analyse des dépendances et la vérification de l’architecture devraient rester obligatoires, quelle que soit la rapidité avec laquelle le code est produit.

Cette approche permet également de réduire les risques opérationnels. Les incidents de sécurité restent rarement confinés aux équipes d’ingénierie. Ils peuvent nuire à la confiance des clients, à la conformité réglementaire, à la continuité opérationnelle et aux performances financières. À mesure que l’IA accélère la mise en production des logiciels, les entreprises doivent veiller à ce que les contrôles de sécurité s’adaptent au rythme de développement.

Il convient également de noter que les modèles d’IA s’appuient sur des référentiels publics contenant à la fois des implémentations sécurisées et non sécurisées. Le modèle n’est pas capable, en soi, de distinguer les modèles conformes aux politiques de votre organisation. Il prédit la solution la plus probable en fonction de son apprentissage.

Pour les dirigeants, les implications sont claires. L’IA doit s’inscrire dans un cycle de vie de développement logiciel sécurisé. Les organisations qui définissent leurs exigences de sécurité dès le début, les intègrent dans leurs processus de développement et exigent une vérification indépendante pourront tirer parti des gains de productivité offerts par l’IA tout en préservant la confiance dans les logiciels qu’elles déploient.

Les outils d’IA font souvent fi des conventions de codage et des bonnes pratiques propres à chaque équipe

Au fil du temps, chaque organisation d’ingénierie élabore ses propres normes. Ces normes portent sur les conventions de nommage, la gestion des erreurs, les limites des services, les attentes en matière de tests, les pratiques de journalisation et bien d’autres aspects du développement logiciel. Elles renforcent la cohérence, simplifient la maintenance et permettent aux équipes de collaborer efficacement sur des bases de code volumineuses.

Les modèles d’IA ne connaissent pas naturellement ces normes internes. À moins qu’elles ne soient explicitement incluses dans les consignes ou mises à disposition par le biais de systèmes d’aide, le modèle génère du code en se basant sur des modèles appris à partir de sources publiques. Le résultat peut être techniquement correct tout en étant en contradiction avec la méthode de développement logicielle privilégiée par l’organisation.

Cela engendre des coûts opérationnels cachés. Les ingénieurs consacrent davantage de temps à réécrire le code généré par l’IA afin de le mettre en conformité avec les conventions internes, au lieu de se concentrer sur la résolution des problèmes métier. Les revues de code s’allongent, car les réviseurs identifient sans cesse les mêmes types de problèmes. Au fil du temps, le manque d’uniformité dans les styles d’implémentation rend les systèmes plus difficiles à maintenir, en particulier lorsque plusieurs équipes contribuent aux mêmes produits.

De nombreuses pratiques d’ingénierie importantes sont rarement documentées dans leur intégralité. Les équipes s’appuient souvent sur l’expérience collective et les connaissances informelles pour faire respecter les normes. L’IA n’a pas accès à ce savoir institutionnel, à moins que les organisations ne le lui fournissent délibérément. À mesure que l’adoption de l’IA se généralise, la documentation de ces normes prend de plus en plus d’importance, car elle profite tant aux développeurs qu’aux systèmes d’IA.

Les recherches confirment cette distinction entre rapidité et qualité. Une étude de l’université Carnegie Mellon (CMU), portant sur 807 référentiels open source, a révélé que les outils d’IA accéléraient le développement, mais ne permettaient pas systématiquement d’obtenir des logiciels de meilleure qualité. La génération plus rapide de code doit donc être considérée comme un gain de capacité de développement.

Pour les dirigeants, cela souligne l’importance de la gouvernance technique. Les normes de codage ne doivent pas se limiter à de simples documents de référence que les développeurs consultent occasionnellement. Elles doivent être intégrées aux flux de travail assistés par l’IA grâce à des consignes réutilisables, à une documentation centralisée, à l’application automatisée des règles et à des environnements de développement qui fournissent à l’IA le contexte technique de l’organisation.

Les organisations devraient également suivre les remarques récurrentes formulées lors des revues. Si les réviseurs soulignent à plusieurs reprises qu’un utilitaire existant aurait dû être réutilisé ou que la gestion des erreurs ne respecte pas les normes internes, le problème ne réside peut-être pas dans les compétences des développeurs. Cela peut indiquer que l’IA passe systématiquement à côté du contexte organisationnel. S’attaquer au processus sous-jacent peut permettre d’obtenir de meilleures améliorations que de corriger sans cesse le même résultat après sa génération.

Les entreprises qui établissent des normes d’ingénierie claires et les rendent facilement accessibles gagneront en cohérence à mesure que l’adoption de l’IA se généralise. L’objectif n’est pas de restreindre la liberté des développeurs, mais de veiller à ce que le code généré par l’IA renforce la plateforme logicielle dans son ensemble, plutôt que d’introduire des variations inutiles.

Le code généré par l’IA présente d’importantes failles de sécurité, car il reproduit des schémas non sécurisés issus des données d’apprentissage publiques

La sécurité mérite une attention particulière, car les logiciels générés par l’IA comportent des risques à la fois prévisibles et évitables. La plupart des problèmes de sécurité identifiés dans le code généré par l’IA ne constituent pas des vulnérabilités hautement spécialisées. Il s’agit de problèmes bien connus que les équipes de développement expérimentées maîtrisent déjà et s’efforcent activement d’éviter.

Les grands modèles linguistiques sont entraînés à partir d’énormes collections de code accessible au public. Ces référentiels contiennent d’excellentes pratiques d’ingénierie, mais aussi des techniques obsolètes, des implémentations non sécurisées et du code vulnérable. Le modèle apprend des modèles à partir de l’ensemble de ces éléments. Il ne détermine pas de manière autonome si un modèle est conforme aux exigences de sécurité modernes ou aux politiques internes d’une organisation.

L’IA peut donc générer du code comportant des failles qui correspondent directement au Top 10 de l’OWASP, cette liste largement reconnue répertoriant les risques de sécurité les plus critiques pour les applications web. Il s’agit notamment de problèmes tels que des défaillances du contrôle d’accès, des vulnérabilités par injection, une authentification non sécurisée et une validation incorrecte. Ces failles constituent des vecteurs d’attaque courants que les équipes de sécurité surveillent activement.

Selon le rapport 2025 de Veracode sur la sécurité du code généré par l’IA (GenAI), 45 % des tâches de codage liées à l’IA comportaient au moins une vulnérabilité figurant dans le classement OWASP Top 10. Pour les dirigeants d’entreprise, ce chiffre mérite une attention particulière. Il suggère que près de la moitié des implémentations générées par l’IA et impliquant des fonctionnalités sensibles en matière de sécurité pourraient nécessiter des mesures correctives avant de pouvoir être mises en production.

Les implications pour l’entreprise vont au-delà de la qualité des logiciels. Les failles de sécurité peuvent entraîner des perturbations opérationnelles, des sanctions réglementaires, une perte de clientèle, des risques juridiques et une atteinte à la réputation. À mesure que les organisations recourent de plus en plus au développement assisté par l’IA, elles doivent veiller à ce que les mesures de sécurité évoluent au même rythme. Accélérer la génération de code sans renforcer la validation de la sécurité augmente les risques pour l’organisation.

Cela implique d’intégrer la sécurité à chaque étape du développement. L’analyse automatisée du code, l’analyse des dépendances, les tests d’intrusion, la détection des informations confidentielles et les revues de sécurité effectuées par des experts doivent rester des pratiques courantes, que le code soit écrit manuellement ou généré par l’IA. La sécurité ne peut pas devenir facultative simplement parce que le développement s’accélère.

Les dirigeants doivent également prendre conscience que le code généré par l’IA peut créer un faux sentiment de confiance. Les modèles modernes produisent des implémentations soignées et lisibles qui réussissent souvent les tests fonctionnels. La justesse fonctionnelle ne constitue toutefois qu’une dimension de la qualité logicielle. Un logiciel sécurisé doit également protéger les données, appliquer les règles d’autorisation, gérer les défaillances en toute sécurité et résister aux techniques d’attaque connues.

Les organisations qui considèrent l’IA comme un levier de productivité tout en maintenant une gouvernance rigoureuse en matière de sécurité seront mieux placées pour en tirer pleinement parti. L’avantage concurrentiel ne viendra pas de la production d’un volume maximal de code, mais de la création de logiciels auxquels les clients, les régulateurs et les parties prenantes peuvent faire confiance.

Le code généré par l’IA a tendance à privilégier le « scénario idéal » tout en négligeant la programmation défensive

L’une des limites les moins visibles du code généré par l’IA réside dans sa tendance à partir du principe que les systèmes se comporteront exactement comme prévu. Dans de nombreux cas, le code généré gère correctement les conditions de fonctionnement normales, mais ne prévoit pas suffisamment les défaillances susceptibles de survenir dans des environnements de production réels.

Les logiciels d’entreprise fonctionnent rarement dans des conditions idéales. Il arrive que des services externes soient indisponibles, que la latence du réseau augmente, que les bases de données soient soumises à des conflits d’accès, que les utilisateurs fournissent des données inattendues et que les requêtes simultanées mettent en évidence des problèmes de synchronisation. Les ingénieurs expérimentés conçoivent des logiciels en tenant compte de ces réalités, car ils y ont été confrontés à maintes reprises. Les modèles d’IA, en revanche, génèrent des solutions basées sur des schémas appris plutôt que sur l’expérience opérationnelle.

Le code généré par l’IA peut omettre des vérifications de valeurs nulles, laisser la gestion des exceptions incomplète, ignorer des conditions d’échec précoces ou négliger des problèmes de concurrence. Ces omissions sont souvent difficiles à détecter, car les tests fonctionnels se concentrent généralement sur le comportement attendu. Le code réussit les tests unitaires, les démonstrations se déroulent sans encombre et le déploiement s’effectue sans signe avant-coureur immédiat.

Les problèmes apparaissent souvent plus tard, dans le cadre de charges de travail en production difficiles à reproduire pendant la phase de développement. Un mécanisme de mise en cache peut fonctionner correctement lors de tests séquentiels, mais présenter des défaillances lorsque de nombreux utilisateurs accèdent simultanément au système. Une gestion des erreurs qui semble suffisante pendant le développement peut s’avérer insuffisante dès lors que des dépendances externes commencent à renvoyer des réponses inattendues.

Les stratégies de test doivent évoluer parallèlement à l’adoption de l’IA. Si l’IA permet aux équipes de générer davantage de code, les entreprises doivent également étendre les tests au-delà de la validation fonctionnelle. Les scénarios de défaillance, les tests de concurrence, les tests de résilience, les tests d’intégration et la simulation de charges de travail proches de celles de production prennent de plus en plus d’importance, car ils permettent d’examiner des conditions que l’IA néglige souvent.

Les études disponibles corroborent cette préoccupation. Le blog « Engineering » de Stack Overflow a indiqué que, si le volume de pull requests a augmenté de 20 % par développeur, le nombre d’incidents par pull request a également augmenté de 23,5 %. Les pull requests générées par l’IA contenaient près de huit fois plus d’opérations d’entrée/sortie que le code rédigé par des humains, ce qui accroît la probabilité que les interactions avec des systèmes externes nécessitent une validation minutieuse.

Pour les dirigeants, l’enjeu principal réside dans la fiabilité opérationnelle. Les clients évaluent rarement un logiciel en fonction de ses performances dans des conditions idéales. Ils l’évaluent plutôt en fonction de la régularité de ses performances lorsque les systèmes sont soumis à des contraintes ou en cas d’événements imprévus. Les entreprises qui investissent dans des tests de résilience plus rigoureux réduiront les incidents de production tout en préservant les gains de productivité apportés par l’IA.

La mise en place de pratiques de vérification rigoureuses est essentielle pour intégrer en toute sécurité le codage assisté par l’IA dans les processus de développement

La plus grande opportunité offerte par l’IA ne réside pas simplement dans un développement logiciel plus rapide. Il s’agit de la capacité à accroître les capacités d’ingénierie sans augmenter les effectifs au même rythme. La concrétisation de cette opportunité dépend d’un facteur essentiel : la vérification.

Chaque étape du développement assisté par l’IA devrait inclure une validation structurée permettant de pallier les limites des modèles linguistiques. Sans cette rigueur, un développement plus rapide ne fait qu’accélérer l’apparition de défauts dans le pipeline de livraison logicielle.

La vérification commence avant la génération du code. L’IA produit de meilleurs résultats lorsque les développeurs fournissent des comptes rendus des décisions architecturales, des normes de codage, des exemples de gestion des erreurs recommandés et d’autres éléments de contexte spécifiques au projet. Des données d’entrée de meilleure qualité augmentent la probabilité que le code généré réponde aux attentes de l’entreprise.

Le processus de révision revêt une importance tout aussi grande. Les développeurs doivent évaluer le code généré par l’IA avec le même niveau de rigueur que celui qu’ils appliqueraient à du code écrit par un ingénieur qu’ils ne connaissent pas. Chaque hypothèse doit être examinée. La logique métier doit être vérifiée de manière indépendante. Les implications en matière de sécurité doivent être évaluées de manière explicite, plutôt que d’être déduites de l’aspect de l’implémentation.

Les dirigeants doivent prendre conscience que la vérification devient une compétence stratégique. L’IA peut accroître considérablement le rendement en matière de développement, mais la capacité de révision n’augmente pas automatiquement dans la même proportion. Si les organisations génèrent deux ou trois fois plus de code tout en conservant les mêmes processus de révision, les équipes d’ingénieurs se retrouvent inévitablement confrontées à une pression croissante. La qualité de la révision risque de baisser, simplement parce que les réviseurs ont davantage de contenu à évaluer dans un laps de temps identique.

Cela implique de repenser les processus d’ingénierie plutôt que de se contenter d’introduire des outils d’IA. Les entreprises devront peut-être améliorer les tests automatisés, investir dans des plateformes d’analyse de code plus performantes, affiner leurs politiques en matière de « pull requests » et établir des normes de révision plus claires. L’objectif n’est pas de ralentir le développement, mais de veiller à ce que l’assurance qualité évolue au même rythme que la vitesse de développement.

La vérification devrait également s’inscrire dans la culture d’entreprise. Les équipes qui valident systématiquement le code généré par l’IA développent, au fil du temps, une discipline d’ingénierie plus rigoureuse. Les développeurs parviennent à identifier plus efficacement les défauts subtils, les relecteurs gagnent en assurance pour remettre en question les implémentations générées par l’IA, et les responsables disposent d’indicateurs plus fiables de la qualité des logiciels.

Les organisations qui tireront le plus grand avantage à long terme de l’IA ne seront pas nécessairement celles qui produisent le plus de code. Ce seront celles qui mettent en place des processus reproductibles garantissant qu’un développement rapide s’accompagne systématiquement d’une validation rigoureuse. Cette combinaison permet à l’IA de devenir un moteur durable d’innovation plutôt qu’une source de risques opérationnels croissants.

L’essor du développement assisté par l’IA met à rude épreuve les processus actuels de révision du code

L’IA a radicalement transformé le rythme de production des logiciels. Les développeurs peuvent désormais générer beaucoup plus de code dans un même laps de temps, ce qui permet aux entreprises de proposer plus rapidement de nouvelles fonctionnalités et d’explorer davantage d’idées. Cette augmentation de la production est précieuse, mais elle met également en évidence un goulot d’étranglement auquel de nombreuses entreprises ne s’attendaient pas : la révision du code.

Les processus de révision n’ont pas évolué au même rythme que le développement assisté par l’IA. Les équipes produisent deux à trois fois plus de code, mais le nombre de réviseurs, le temps consacré à la révision et le processus global de gouvernance restent souvent inchangés. En conséquence, on attend des réviseurs qu’ils évaluent un volume de code nettement plus important sans bénéficier de ressources supplémentaires ni d’outils d’aide plus performants.

Cela ne se limite pas à la rapidité de la révision. Les pull requests générées par l’IA sont souvent plus volumineuses et contiennent moins d’explications sur les raisons qui ont motivé les choix d’implémentation. Si les messages de commit décrivent certes les modifications apportées, ils omettent fréquemment le raisonnement qui sous-tend ces changements. Les réviseurs doivent donc consacrer davantage de temps à reconstituer le contexte avant de pouvoir évaluer si l’implémentation est conforme aux exigences métier et aux normes architecturales.

Une augmentation du volume des demandes de modification (pull requests) sans augmentation correspondante des résultats commerciaux obtenus peut indiquer que les équipes produisent davantage de code plutôt que de générer davantage de valeur. Une rotation accrue du code suggère que les modifications sont fusionnées avant d’avoir été entièrement validées. Des cycles de révision plus longs reflètent souvent l’effort supplémentaire nécessaire pour vérifier les implémentations générées par l’IA, plutôt qu’un manque d’efficacité au sein de l’équipe d’ingénierie.

Les défauts logiques et les erreurs liées aux règles métier méritent également une attention particulière. Les modèles d’IA modernes produisent généralement un code syntaxiquement correct, ce qui signifie que les erreurs de programmation élémentaires sont devenues moins fréquentes. Les problèmes restants sont souvent plus difficiles à identifier, car ils relèvent davantage de la prise de décision que de la syntaxe. La détection de ces problèmes nécessite des relecteurs dotés d’une solide connaissance du domaine.

Les pull requests faisant largement appel à l’IA ont nécessité des cycles de révision environ 25 % plus longs, et les équipes constatent souvent que ces pull requests ont deux à trois fois plus de chances d’être rejetées. Il s’agit là d’indicateurs opérationnels précieux, car ils permettent de déterminer si l’accélération du développement se traduit par une livraison durable de logiciels ou si elle ne fait que générer des retouches supplémentaires.

Pour les dirigeants, cela modifie la manière dont les performances techniques doivent être évaluées. Des indicateurs tels que la fréquence de déploiement et la vitesse de développement restent utiles, mais ils doivent être mis en balance avec des indicateurs qui mesurent la qualité des logiciels. La durée des revues, les taux de défauts, le taux de renouvellement du code, les incidents en production et la fréquence des retours en arrière offrent une vision plus complète des performances techniques dans un environnement assisté par l’IA.

Les organisations devraient également investir dans l’amélioration de l’efficacité des relecteurs plutôt que de se concentrer exclusivement sur la productivité des développeurs. L’analyse statique automatisée, les analyses de sécurité, les modèles standardisés de pull requests, les listes de contrôle architecturales et une documentation plus complète peuvent réduire la charge de travail des relecteurs tout en améliorant la cohérence. Ces investissements contribuent à garantir que la gouvernance évolue au même rythme que l’adoption de l’IA, au lieu de devenir un frein à la livraison.

En fin de compte, la révision de code devient une compétence stratégique plutôt qu’une simple tâche technique courante. Les entreprises qui renforcent cette fonction seront mieux à même de maintenir la qualité à mesure que l’IA continue d’accroître les capacités de développement logiciel.

L’IA ne permet d’obtenir des gains de productivité significatifs que lorsqu’elle s’accompagne de pratiques rigoureuses en matière d’ingénierie et de vérification

Les gains de productivité liés à l’IA sont réels et de plus en plus mesurables. Les équipes de développement peuvent accomplir plus rapidement les tâches de codage courantes, réduire les tâches répétitives et consacrer davantage de temps à la résolution de problèmes à plus forte valeur ajoutée. Cela offre des opportunités significatives aux organisations qui cherchent à accélérer l’innovation et à améliorer l’efficacité de leurs équipes d’ingénierie.

Ces avantages ne peuvent être durables que s’ils s’appuient sur des pratiques d’ingénierie rigoureuses. L’IA ne doit pas être considérée comme un substitut aux principes fondamentaux du génie logiciel. Elle doit au contraire venir renforcer les équipes qui appliquent déjà des normes rigoureuses en matière de conception, de tests, de sécurité, de documentation et de révision.

Cette distinction est importante, car l’IA modifie les domaines sur lesquels se concentrent les efforts d’ingénierie. Les développeurs consacrent moins de temps à l’écriture de code standard et davantage à la validation de la logique métier, à la vérification des implémentations générées, à l’affinage des invites et à la vérification du bon fonctionnement du logiciel dans des conditions d’exploitation réelles. La nature du travail d’ingénierie évolue, mais le besoin d’expertise ne diminue pas.

Selon le « Dev Barometer » du troisième trimestre 2025 publié par BairesDev, les développeurs gagnent en moyenne 7,3 heures de codage par semaine lorsqu’ils utilisent des outils d’IA. Cela représente une augmentation significative des capacités techniques disponibles. Les entreprises peuvent mettre à profit ces heures économisées pour améliorer la livraison des produits, réduire les retards, renforcer les tests, moderniser les systèmes existants ou investir dans l’innovation. La valeur ajoutée provient de la réorientation des efforts d’ingénierie, et non de la suppression de cette discipline.

Les organisations performantes considèrent l’adoption de l’IA comme un processus et une initiative culturelle plutôt que comme un simple déploiement technologique. Les équipes qui définissent des attentes claires avant d’étendre l’utilisation de l’IA obtiennent systématiquement de meilleurs résultats que celles qui tentent de résoudre les problèmes de gouvernance une fois que ceux-ci sont apparus. La définition de normes de révision, la documentation des pratiques d’ingénierie, la mise à jour des supports d’intégration et l’intégration d’exigences de vérification dans les modèles de pull request permettent d’assurer une cohérence à l’échelle de l’organisation.

Pour les dirigeants, il s’agit d’une responsabilité importante en matière de direction. L’adoption de l’IA doit s’accompagner d’investissements dans les ressources humaines, les processus et la gouvernance, parallèlement aux investissements technologiques. La réussite dépend de l’alignement des objectifs d’ingénierie, des exigences de sécurité, des attentes en matière de conformité et des normes opérationnelles sur les capacités offertes par le développement assisté par l’IA.

Les organisations devraient également redéfinir la manière dont le succès est mesuré. L’objectif n’est pas de maximiser la quantité de code généré. L’objectif est de fournir des logiciels fiables, sécurisés et faciles à maintenir, qui créent de la valeur pour l’entreprise. Les indicateurs de productivité devraient donc être évalués parallèlement à la satisfaction client, à la stabilité de la production, aux résultats en matière de sécurité et à la maintenabilité à long terme.

Les entreprises qui parviennent à trouver cet équilibre se forgeront un avantage concurrentiel durable. Elles seront en mesure de livrer des logiciels plus rapidement tout en préservant la confiance en matière de qualité, de sécurité et de résilience opérationnelle. L’IA permet cette accélération. C’est une culture d’ingénierie solide qui détermine si cette accélération génère une valeur commerciale durable.

Récapitulation

L’IA s’impose désormais dans toutes les entreprises de logiciels modernes. La question n’est plus de savoir si vos équipes vont l’utiliser. La question est de savoir si votre entreprise mettra en place le modèle opérationnel nécessaire pour en tirer pleinement parti.

Les entreprises qui en tirent le plus grand avantage ne se contentent pas de produire davantage de code. Elles améliorent l’ensemble du système de déploiement logiciel autour de l’IA. Elles renforcent les revues de code, développent les tests automatisés, documentent les choix architecturaux et intègrent la vérification de la sécurité à chaque version. L’IA accroît les capacités d’ingénierie. Ce sont des processus solides qui déterminent si ces capacités génèrent une valeur commerciale durable.

Pour les dirigeants, cela implique de repenser la manière dont le développement logiciel est évalué. Une accélération du rythme de développement est certes encourageante, mais elle ne doit jamais être considérée isolément. La qualité des logiciels, la stabilité de la production, les résultats en matière de sécurité, l’expérience client et la facilité de maintenance restent les indicateurs qui déterminent en fin de compte la réussite de l’entreprise. Une livraison plus rapide n’a de valeur que si elle produit systématiquement des résultats fiables.

C’est également l’occasion de repenser la culture de l’ingénierie. L’IA modifie le rôle des développeurs, qui ne se limitent plus principalement à écrire du code, mais doivent de plus en plus l’évaluer, le valider et l’améliorer. Les organisations qui investissent dès aujourd’hui dans ces compétences seront mieux placées à mesure que les capacités de l’IA continueront de progresser. La vérification, la réflexion critique et le jugement technique deviendront encore plus précieux.

Le leadership joue un rôle central dans cette transition. L’adoption de l’IA doit s’appuyer sur une gouvernance claire, des normes de qualité réalistes, des indicateurs techniques mesurables et un investissement continu dans les compétences des développeurs. L’objectif n’est pas de freiner l’innovation en multipliant les processus, mais de garantir que l’innovation puisse se développer à grande échelle sans accroître le risque opérationnel.

Les gagnants à long terme ne seront pas ceux qui auront été les premiers à adopter l’IA. Ce seront ceux qui auront mis en place les méthodes nécessaires pour l’utiliser de manière responsable, sécurisée et cohérente. L’IA est un puissant accélérateur. Les organisations qui sauront associer cette accélération à des pratiques d’ingénierie solides seront en mesure de livrer des logiciels plus rapidement, de gagner davantage la confiance de leurs clients et de bâtir une entreprise plus résiliente pour les années à venir.