Comment adopter les LLM tout en garantissant un code de qualité

Les outils de programmation basés sur l’IA ne permettent d’améliorer la productivité que pour des tâches spécifiques et bien définies

Le débat sur le codage assisté par l’IA commence souvent par la présentation de chiffres impressionnants en matière de productivité. Ces chiffres sont réels, mais ils ne reflètent pas toute la réalité. La question importante n’est pas de savoir si l’IA permet aux développeurs de travailler plus vite. La question importante est de savoir dans quels domaines elle leur permet de gagner en rapidité.

L’IA donne le meilleur d’elle-même lorsque le travail est répétitif, structuré et facile à définir. Elle peut générer du code standard, créer de la documentation, rédiger des tests unitaires, développer des prototypes simples et aider les développeurs à déboguer des problèmes courants. Ces tâches suivent des schémas bien établis, que les grands modèles linguistiques savent très bien reconnaître et reproduire. Au lieu de consacrer du temps à des implémentations répétitives, les ingénieurs peuvent se concentrer davantage sur la résolution des problèmes métier et l’amélioration des produits.

La situation change lorsque le travail requiert un jugement plutôt qu’une simple reconnaissance de modèles. Les décisions concernant l’architecture logicielle, l’authentification, l’autorisation, le chiffrement, la configuration de l’infrastructure ou la logique métier sensible exigent une compréhension approfondie du fonctionnement de l’ensemble du système. L’IA ne dispose pas de cette compréhension. Elle génère des réponses basées sur des probabilités, et non sur une connaissance réelle de votre entreprise, de vos clients ou de votre environnement technologique.

Cette distinction est importante car de nombreuses organisations évaluent encore le codage basé sur l’IA à l’aide d’un seul indicateur de productivité. Cela engendre des attentes irréalistes. Une équipe peut mener à bien des tâches de développement simples beaucoup plus rapidement, tout en ne constatant que peu d’amélioration, voire un ralentissement des délais de livraison, sur des projets de grande envergure et interconnectés. Se concentrer uniquement sur la productivité moyenne masque ces différences.

Les données corroborent cette vision plus nuancée. Une étude contrôlée menée par GitHub a révélé que les développeurs accomplissaient leurs tâches 55,8 % plus rapidement grâce à Copilot. Une autre étude menée auprès de plusieurs entreprises et portant sur 5 000 développeurs a fait état d’une augmentation moyenne de la productivité de 26 %. Il s’agit là d’améliorations significatives. Parallèlement, les données du secteur montrent systématiquement que ces gains dépendent fortement de la complexité des tâches, de l’expérience des développeurs et de l’environnement logiciel.

Le comportement des développeurs reflète cette réalité. Selon l’enquête 2025 de Stack Overflow, 76 % des développeurs choisissent de ne pas utiliser d’outils d’IA pour le déploiement ou la surveillance. Ils ont déjà identifié les domaines dans lesquels l’IA apporte une valeur ajoutée et ceux où les risques l’emportent sur les avantages.

Pour les dirigeants, la conclusion est claire. L’IA ne doit pas être introduite dans le but de se substituer de manière générale au travail d’ingénierie. Elle doit être déployée de manière réfléchie dans les domaines où elle produit systématiquement des résultats fiables. Les organisations qui définissent ces limites dès le départ ont davantage de chances d’améliorer leur productivité sans créer de risques opérationnels ou de sécurité inutiles.

Les développeurs surestiment souvent les gains de productivité liés à l’IA

L’une des constatations les plus intéressantes concernant le développement logiciel assisté par l’IA est que les personnes ont souvent l’impression de travailler plus vite, même lorsque des mesures objectives démontrent le contraire.

Cela est important car les décisions de la direction sont souvent influencées par les retours des collaborateurs et leur perception de l’efficacité. Si les développeurs ont systématiquement le sentiment d’être plus productifs alors que la livraison effective ralentit, les entreprises risquent d’investir dans des processus qui semblent fructueux mais qui produisent des résultats commerciaux moins bons.

L’étude METR publiée en juillet 2025 l’illustre clairement. Les chercheurs ont demandé à seize développeurs open source expérimentés de résoudre des problèmes logiciels concrets à l’aide de Cursor Pro et de Claude Sonnet. Avant de commencer, les développeurs s’attendaient à ce que l’IA augmente leur productivité de 24 %. Une fois le travail terminé, les résultats mesurés ont montré qu’ils avaient en réalité mis 19 % plus de temps que les développeurs travaillant sans IA.

C’est ce qui s’est passé ensuite qui a été surprenant.

Même après avoir pris connaissance de leurs propres résultats, les participants continuaient de penser que l’IA leur avait permis de gagner environ 20 % de temps. Leur perception n’a pratiquement pas évolué, malgré des preuves mesurables indiquant que c’était tout le contraire qui s’était produit.

Cela met en évidence un enjeu important en matière de gestion. L’IA réduit le nombre de frappes et les tâches de codage répétitives. Les développeurs consacrent davantage de temps à examiner les suggestions qu’à écrire eux-mêmes chaque ligne de code. Cette expérience donne souvent l’impression d’être plus rapide, car elle nécessite moins d’efforts manuels. Cependant, une réduction de l’effort ne se traduit pas automatiquement par une réalisation plus rapide du projet ni par un logiciel de meilleure qualité.

Cette différence entre la productivité perçue et la productivité mesurée prend encore plus d’importance à mesure que les projets prennent de l’ampleur. Les petites tâches peuvent tirer parti d’une génération rapide de code. Les projets de plus grande envergure impliquent en revanche des travaux d’intégration, des revues de code, des tests, la validation de l’architecture et la vérification de la sécurité. Ces activités déterminent souvent la rapidité de livraison bien plus que l’écriture du code elle-même.

Les dirigeants devraient donc évaluer l’IA à l’aide d’indicateurs opérationnels plutôt que de se fier uniquement à l’impression générale. La durée du cycle, les défauts de production, la fréquence des déploiements, les incidents clients, les constatations en matière de sécurité et l’effort de maintenance fournissent une image bien plus précise que de simplement demander aux équipes si elles se sentent plus productives.

Cela ne diminue en rien la valeur de l’IA. Cela modifie simplement la manière dont il convient de mesurer son succès.

Les organisations qui en tireront le plus grand avantage seront celles qui sauront faire la distinction entre perception et performance. Elles évalueront en permanence les domaines dans lesquels l’IA génère une valeur commerciale mesurable, adapteront son utilisation en conséquence et éviteront d’étendre son utilisation à des domaines où les données disponibles ne permettent pas de constater d’améliorations significatives. Cette approche permet d’obtenir des gains durables plutôt qu’un enthousiasme passager.

Le code généré par l’IA pourrait entraîner une augmentation des coûts de maintenance à long terme

Générer du code plus rapidement ne revient pas à développer des logiciels qui restent performants à long terme. Cette distinction revêt une importance croissante à mesure que les entreprises recourent de plus en plus aux assistants de codage basés sur l’IA.

Les grands modèles linguistiques sont optimisés pour produire du code rapidement. Ils ne sont pas conçus pour réduire les coûts de maintenance à long terme. Si elle n’est pas contrôlée, l’IA peut générer des implémentations répétitives, dupliquer des fonctionnalités existantes et introduire du code qui fonctionne aujourd’hui mais qui deviendra difficile à maintenir demain. Aucun de ces problèmes n’est forcément visible pendant la phase initiale de développement, mais ils s’accumulent au fil du temps.

L’une des raisons est que l’IA a tendance à résoudre le problème immédiat présenté dans la consigne. Elle ne se demande pas automatiquement si une fonctionnalité similaire existe déjà ailleurs dans la base de code ou s’il ne vaudrait pas mieux étendre un composant existant. Il en résulte souvent plusieurs implémentations d’une même idée, dispersées dans différentes parties d’un système.

À mesure que les doublons se multiplient, chaque modification future devient plus coûteuse. Les ingénieurs doivent identifier tous les emplacements concernés, vérifier que le comportement reste cohérent et réduire le risque d’introduire des différences involontaires entre des segments de code similaires. Parallèlement, les occasions de simplifier ou de moderniser la base de code par le biais de la refactorisation se font plus rares, car les résultats générés par l’IA sont souvent acceptés tels quels dès lors qu’ils ont passé les tests initiaux.

L’analyse à grande échelle menée par GitClear met en évidence cette tendance. Après avoir examiné 211 millions de lignes de code modifiées, l’entreprise a constaté que la duplication de code avait quadruplé entre 2021 et 2024. Au cours de la même période, les activités de refactorisation sont passées de 25 % des lignes modifiées à moins de 10 %.

Ces conclusions devraient préoccuper les dirigeants d’entreprise, car la maintenabilité a une incidence directe sur la rapidité de livraison, la qualité des logiciels et les coûts d’exploitation. La dette technique apparaît rarement dans les rapports trimestriels sur la productivité, mais elle finit par affecter la capacité de développement, la gestion des incidents, l’expérience client et les budgets d’ingénierie.

L’objectif n’est pas de générer davantage de code. L’objectif est de produire un code qui reste compréhensible, sécurisé et adaptable pendant de nombreuses années. L’IA devrait donc s’aligner sur les normes d’ingénierie existantes plutôt que d’inciter les équipes à privilégier le volume de production au détriment de la qualité logicielle.

Les organisations qui vérifient le code généré par l’IA afin de détecter les doublons, d’assurer la cohérence architecturale et de garantir la maintenabilité seront mieux à même de tirer parti des gains de productivité sans engendrer de coûts opérationnels à long terme.

Les organisations doivent définir clairement dans quels domaines l’IA doit être utilisée et dans lesquels l’expertise humaine reste indispensable

La réussite de la mise en œuvre de l’IA dépend moins de la technologie elle-même que de la gouvernance. Chaque organisation devrait définir des limites claires pour déterminer les domaines dans lesquels l’IA est encouragée et ceux où la prise de décision humaine est obligatoire.

Toutes les tâches d’ingénierie logicielle ne présentent pas le même niveau de risque. Certaines activités sont très structurées et faciles à vérifier. D’autres ont une incidence directe sur la sécurité, la conformité, la confiance des clients ou la continuité d’activité. Traiter ces tâches de la même manière entraîne des risques inutiles.

L’IA apporte une grande valeur ajoutée dans le cadre de tâches prévisibles telles que la génération de code standard, la rédaction de documentation, la création de tests unitaires, la refactorisation de modèles bien maîtrisés, la création de prototypes et l’aide au débogage. Ces activités sont relativement faciles à vérifier et à valider par les développeurs avant le déploiement.

Les tâches à haut risque nécessitent une approche différente. L’authentification, l’autorisation, les implémentations cryptographiques, le traitement des données sensibles, la configuration de l’infrastructure, l’architecture du système et la logique métier critique dépendent toutes de connaissances organisationnelles que l’IA ne possède tout simplement pas. Ces décisions exigent une bonne compréhension des obligations réglementaires, des politiques internes, des engagements pris envers les clients et de l’environnement technologique au sens large.

Cette limite n’est pas un problème temporaire qui disparaîtra avec des modèles plus performants. L’IA génère des réponses en s’appuyant sur des modèles disponibles plutôt que sur une compréhension précise des systèmes, des priorités ou de l’historique opérationnel de votre organisation. À moins que ce contexte ne soit délibérément fourni, des hypothèses importantes peuvent facilement être négligées.

Le rapport « Qodo State of AI Code Quality » confirme cette difficulté. Il révèle que 65 % des développeurs estiment que l’IA passe à côté de contextes pertinents lors de tâches critiques. Parmi les développeurs ayant constaté une baisse de qualité du code généré par l’IA, 44 % ont identifié l’absence de contexte comme la cause principale.

Le contexte métier représente un autre défi. Selon le Dev Barometer du troisième trimestre 2025 de BairesDev, 43 % des chefs de projet interrogés ont identifié les lacunes en matière de connaissance du contexte métier comme le principal défi lié aux compétences pour l’adoption de l’IA. Ce défi devance la pénurie de spécialistes en IA et en apprentissage automatique (41 %) ainsi que l’insuffisance des programmes de perfectionnement (38 %).

Pour les dirigeants, ces conclusions mettent en évidence un problème de gouvernance plutôt qu’un problème technologique. L’IA doit s’inscrire dans le cadre de politiques clairement définies, précisant les cas d’utilisation autorisés, les activités soumises à restriction, les exigences en matière de contrôle et les procédures d’escalade. Ces politiques doivent être harmonisées entre les différentes équipes d’ingénierie afin que les attentes ne varient pas d’un projet à l’autre.

Les organisations qui définissent ces limites dès le début amélioreront la cohérence, réduiront les risques inutiles et permettront aux ingénieurs de concentrer l’IA là où elle apporte le plus de valeur. L’objectif n’est pas de maximiser l’utilisation de l’IA. L’objectif est de maximiser les résultats commerciaux tout en respectant les normes requises pour garantir la sécurité et la fiabilité des logiciels.

Le développement assisté par l’IA comporte des risques de sécurité qui nécessitent la mise en place de contrôles rigoureux

L’IA est capable de générer du code sécurisé, mais elle peut également générer du code non sécurisé avec le même niveau de certitude. C’est pourquoi la sécurité ne peut pas être considérée comme une étape facultative de vérification dans le cadre du développement assisté par l’IA. Elle doit être intégrée dès le début au processus de développement.

Les grands modèles linguistiques génèrent du code en prédisant des schémas à partir de leurs données d’entraînement et des consignes qui leur sont fournies. Ils ne comprennent pas l’architecture de sécurité de votre organisation, ses politiques de contrôle d’accès, ses obligations réglementaires ni son modèle de menaces, à moins que ces informations ne leur soient explicitement fournies. Même dans ce cas, ils ne sont pas en mesure de vérifier de manière indépendante si l’implémentation générée répond à ces exigences.

Cela engendre des risques dans des domaines où de petites erreurs peuvent avoir des conséquences importantes. L’authentification, l’autorisation, les implémentations cryptographiques, le traitement des données sensibles et la configuration de l’infrastructure exigent une grande précision. Une seule étape de validation omise ou une vérification d’autorisation incorrecte peut passer inaperçue pendant le développement, mais peut créer des vulnérabilités exploitables après le déploiement.

Le défi est d’autant plus difficile que le code généré par l’IA semble souvent bien structuré et lisible. Une mise en forme soignée et des modèles de codage familiers peuvent inspirer confiance lors des revues, même lorsque d’importantes failles de sécurité restent cachées. Par conséquent, les réviseurs doivent évaluer la logique sous-jacente au lieu de partir du principe qu’un code bien écrit est sécurisé.

Des études montrent pourquoi les organisations devraient considérer cela comme un enjeu de gouvernance plutôt que comme un simple problème technique isolé. Le rapport « 2025 GenAI Code Security Report » de Veracode a évalué plus de 100 grands modèles linguistiques et a révélé que 45 % des tâches de codage basées sur l’IA présentaient des vulnérabilités figurant dans le Top 10 de l’OWASP. Les implémentations Java ont affiché des taux d’échec supérieurs à 70 %, tandis que les mesures de protection contre les attaques de type « cross-site scripting » (XSS) ont échoué dans 86 % des cas.

Il ne s’agit pas là de vulnérabilités obscures. Elles constituent des failles de sécurité courantes que les équipes de développement expérimentées connaissent déjà et s’efforcent activement d’éviter. L’IA peut réintroduire ces problèmes à son insu, à moins que les organisations ne mettent en place des contrôles efficaces.

Les résultats d’Apiiro viennent étayer cette même conclusion. Son étude de 2025 a révélé que les développeurs aidés par l’IA produisaient quatre fois plus de commits que ceux travaillant sans IA, mais qu’ils généraient également dix fois plus de problèmes de sécurité. La génération plus rapide de code augmente le volume de logiciels intégrés au pipeline de développement, ce qui rend la validation automatisée de la sécurité et une révision rigoureuse encore plus importantes.

Pour les dirigeants, cela modifie la manière dont les investissements dans l’IA doivent être évalués. Les indicateurs de productivité ne suffisent pas à eux seuls. Les résultats en matière de sécurité doivent être mesurés parallèlement à la vitesse de développement. Les organisations doivent surveiller les taux de vulnérabilité, les délais de correction des failles de sécurité, les constatations en matière de conformité et les incidents de production afin de déterminer si l’IA génère une valeur commerciale durable.

L’IA devrait permettre d’accélérer la mise à disposition des logiciels sans pour autant compromettre les normes d’ingénierie. Cela n’est possible que si la sécurité reste une composante à part entière de chaque étape du développement, plutôt que d’être abordée après coup, juste avant la mise en production.

La rédaction de spécifications claires avant la génération du code permet d’obtenir de meilleurs résultats en matière d’IA

L’une des méthodes les plus simples pour améliorer le code généré par l’IA est également l’une des plus efficaces : définir le travail à réaliser avant de demander à l’IA de le générer.

De nombreuses équipes abordent l’IA en rédigeant des consignes générales et en s’attendant à des implémentations précises. Cela conduit souvent à des révisions inutiles, car le modèle comble les détails manquants en se basant sur des hypothèses plutôt que sur des connaissances spécifiques au projet. Le code ainsi généré peut fonctionner correctement pris isolément, tout en ne répondant pas aux exigences architecturales, de sécurité ou métier.

Une approche axée sur la spécification change la donne. Avant de lancer un assistant de codage basé sur l’IA, les développeurs doivent décrire ce que le code doit accomplir, ce qu’il doit éviter, les systèmes sur lesquels il aura une incidence et la manière dont le succès sera vérifié. Même un plan écrit succinct permet de définir un objectif plus clair tant pour le développeur que pour le système d’IA.

Les ingénieurs doivent préparer au moins un bref plan de trois phrases abordant trois questions essentielles : en quoi consiste la modification, quelles parties du système sont concernées et comment la mise en œuvre sera-t-elle testée ? Cette planification sommaire réduit le risque que l’IA génère de grandes quantités de code allant dans la mauvaise direction et minimise les retouches inutiles.

La qualité des prompts a également un impact significatif sur la qualité du résultat. Les équipes hautement performantes fournissent des contraintes techniques, des bibliothèques approuvées, des conventions de nommage, des exigences architecturales et des instructions explicites décrivant ce que l’IA ne doit pas faire. Elles demandent également au modèle d’expliquer ses hypothèses et d’identifier les cas limites potentiels avant de générer le code d’implémentation.

Cette approche améliore la cohérence, car l’IA dispose ainsi du contexte organisationnel qui lui ferait autrement défaut. Elle rend également les révisions plus efficaces, car les réviseurs peuvent comparer le code généré à des attentes prédéfinies, au lieu d’essayer de deviner l’intention initiale du développeur une fois la mise en œuvre terminée.

Les recherches de Qodo démontrent en quoi un contexte supplémentaire améliore les résultats. Les équipes ayant utilisé un contexte stocké de manière persistante ont réduit leur taux d’erreurs liées au contexte de 54 % à 16 %. Cela montre que les performances de l’IA s’améliorent considérablement lorsqu’elle dispose d’un accès constant aux connaissances de l’organisation, plutôt que de se fier à des invites isolées.

Pour les dirigeants, la leçon à retenir est claire. L’adoption de l’IA doit s’accompagner non seulement d’outils techniques, mais aussi de normes et d’exigences de spécification précises. Les organisations qui investissent dans des pratiques de développement rigoureuses obtiendront des résultats d’IA plus fiables, réduiront les retouches, renforceront la sécurité et amélioreront la cohérence de la livraison logicielle au fil du temps.

Une révision rigoureuse du code par des humains reste indispensable dans le cadre du développement assisté par l’IA

À mesure que l’IA devient de plus en plus capable de générer du code prêt à être déployé en production, l’importance de la révision humaine augmente plutôt qu’elle ne diminue. L’IA peut réduire le temps nécessaire à l’écriture du code, mais elle ne peut pas se substituer au jugement requis pour déterminer si ce code a sa place dans un système de production.

L’un des principaux défis liés au code généré par l’IA réside dans le fait qu’il semble souvent correct. La syntaxe est soignée, la mise en forme est cohérente et l’implémentation suit généralement des modèles de programmation familiers. Cela crée un faux sentiment de confiance. Les véritables problèmes se situent souvent au niveau de la logique métier, des contrôles de sécurité, de la gestion des erreurs, des cas limites ou des choix architecturaux qui nécessitent une connaissance approfondie du système dans son ensemble.

Les relecteurs humains comprennent les normes organisationnelles, les exigences des clients, les contraintes opérationnelles et les compromis qui sous-tendent les décisions techniques antérieures. Ce n’est pas le cas de l’IA. Un relecteur est capable de déterminer si un code généré fonctionne techniquement, mais s’il entre en conflit avec l’orientation architecturale à long terme ou s’il introduit une complexité inutile.

Les organisations devraient donc mettre à jour leur processus de révision du code afin de tenir compte des risques associés aux logiciels générés par l’IA. Chaque pull request devrait clairement expliquer son objectif, son périmètre, les choix de mise en œuvre et les tests effectués. Les réviseurs devraient accorder une attention particulière à la cohérence de l’architecture, à la validation des données d’entrée, au choix des dépendances, à la logique d’autorisation, à la gestion des exceptions et aux interactions avec les services existants.

Le code sensible sur le plan de la sécurité mérite un niveau de contrôle encore plus rigoureux. Les modifications concernant l’authentification, l’autorisation, les fonctions cryptographiques, les systèmes de paiement, les données réglementées ou l’identité des clients devraient faire l’objet d’un examen obligatoire par des ingénieurs expérimentés avant d’être validées. Ces contrôles devraient s’appliquer, que le code ait été entièrement écrit par un développeur ou généré à l’aide de l’IA.

Cette étude montre pourquoi les revues structurées restent indispensables. Selon l’enquête 2025 de Stack Overflow, 46 % des développeurs se méfient ouvertement de la précision des outils d’IA, tandis que 66 % ont déclaré rencontrer des difficultés avec des solutions générées par l’IA qui sont « presque correctes, mais pas tout à fait ». Ces réponses partiellement correctes nécessitent souvent davantage d’efforts de révision que du code manifestement incorrect, car les défauts subtils sont plus difficiles à détecter.

L’expérience influence également la manière dont les développeurs perçoivent les résultats générés par l’IA. Qodo a constaté que 60 % des développeurs ayant moins de deux ans d’expérience se sentaient en confiance pour déployer du code généré par l’IA sans révision préalable. Parmi les développeurs ayant plus de dix ans d’expérience, seuls 26 % ont exprimé la même confiance. Cette différence suggère que les ingénieurs expérimentés sont davantage conscients des risques cachés que peut présenter le code généré par l’IA.

Pour les dirigeants, cela a des implications directes sur la gouvernance de l’ingénierie. La qualité des révisions ne doit pas dépendre du jugement individuel ni de la confiance des développeurs. Les politiques de révision obligatoires garantissent la cohérence entre les équipes et réduisent le risque que des défauts importants parviennent en production simplement parce que quelqu’un a supposé que l’IA avait produit une solution correcte.

L’IA modifie la manière dont le code est écrit, mais elle ne remet pas en cause la nécessité d’une responsabilité technique. La révision humaine reste l’un des moyens de contrôle les plus efficaces pour garantir la qualité des logiciels, protéger les clients et réduire les risques opérationnels à long terme.

La vérification automatisée devrait faire partie intégrante de tout processus de développement assisté par l’IA

La vérification humaine est essentielle, mais elle ne suffit pas à elle seule. À mesure que l’IA accélère le rythme de développement, les entreprises ont également besoin de systèmes de vérification automatisés capables d’évaluer chaque modification du code de manière cohérente et à grande échelle.

L’IA permet aux développeurs de produire nettement plus de code en moins de temps. Cette augmentation de la production accroît également le risque que des défauts, des failles de sécurité, des erreurs de configuration et des problèmes de dépendances viennent perturber le cycle de vie du développement logiciel. La révision manuelle ne suffit pas à elle seule à suivre de manière fiable ce volume accru.

La vérification automatisée garantit un niveau de qualité constant. Toute modification générée par l’IA doit être soumise au même processus de validation que le code entièrement écrit par des humains. Cela inclut les tests unitaires, les tests d’intégration, l’analyse statique du code, l’analyse de la composition logicielle, les analyses de sécurité, le linting et les pipelines d’intégration continue qui rejettent automatiquement les modifications ne respectant pas les normes de qualité prédéfinies.

Selon Tricentis, 75 % des entreprises ont identifié les tests basés sur l’IA comme une priorité stratégique pour 2025, mais seules 16 % d’entre elles les avaient effectivement mis en œuvre. Ce décalage conduit de nombreuses entreprises à multiplier les résultats générés par l’IA sans pour autant renforcer les processus de validation nécessaires pour les étayer.

La même tendance se dégage du « Dev Barometer » de BairesDev, qui a interrogé 1 129 ingénieurs. Seuls 15 % d’entre eux ont cité la rationalisation des tests comme l’un des principaux avantages de l’IA, tandis que 12 % seulement estimaient que l’IA aidait à détecter les bogues plus tôt dans le processus de développement. Ces résultats suggèrent que de nombreuses entreprises n’ont pas encore constaté d’améliorations significatives de la qualité de leurs logiciels, malgré le développement de leur utilisation de l’IA.

L’automatisation de la sécurité mérite une attention particulière. Le rapport « 2025 GenAI Code Security Report » de Veracode a révélé que 45 % des tâches de codage liées à l’IA généraient des vulnérabilités figurant dans le classement OWASP Top 10. Les tests de sécurité automatisés deviennent donc une mesure de protection essentielle plutôt qu’une amélioration facultative. Les analyses de sécurité doivent être intégrées directement dans les pipelines d’intégration continue afin que les vulnérabilités soient identifiées avant le déploiement, et non après la mise en production.

La validation des dépendances est un autre domaine dans lequel l’automatisation s’avère de plus en plus utile. Les modèles d’IA génèrent parfois des références à des progiciels qui n’existent pas réellement. Des chercheurs ont examiné 2,23 millions de références de bibliothèques générées par l’IA et ont constaté que 19,7 % d’entre elles étaient fictives. Plus inquiétant encore, 43 % de ces noms de bibliothèques inexistantes apparaissaient de manière répétée dans différentes requêtes, offrant ainsi aux pirates la possibilité d’enregistrer ces noms et de diffuser des logiciels malveillants.

L’analyse automatisée de la composition des logiciels permet de détecter ces dépendances invalides ou à risque avant qu’elles ne soient intégrées aux systèmes de production. Associés à la vérification des paquets par rapport à des registres fiables, ces contrôles réduisent considérablement les risques liés à la chaîne d’approvisionnement.

Pour les dirigeants d’entreprise, la vérification automatisée doit être considérée comme une infrastructure fondamentale pour une adoption responsable de l’IA. Elle permet d’accélérer la mise en production des logiciels tout en garantissant une qualité constante, en renforçant la sécurité et en améliorant la conformité. Les organisations qui automatisent efficacement la validation pourront développer en toute confiance leurs activités de développement assistées par l’IA, car chaque modification du code sera évaluée au regard des mêmes normes d’ingénierie avant d’être déployée en production.

La traçabilité et la conformité prennent de plus en plus d’importance à mesure que l’IA génère davantage de code de production

L’intelligence artificielle occupant une place de plus en plus importante dans le développement logiciel, les entreprises doivent savoir précisément comment le code a été créé, révisé, testé et validé. La traçabilité n’est plus simplement une bonne pratique en matière de développement. Elle devient une exigence métier fondamentale.

L’IA modifie la rapidité de mise en production des logiciels, mais elle ne diminue en rien la responsabilité d’une organisation en matière de sécurité, de conformité ou de fiabilité opérationnelle. Chaque ligne de code déployée en production doit pouvoir être justifiée, qu’elle provienne d’un développeur, d’un assistant IA ou d’une combinaison des deux.

GitHub Copilot génère désormais environ 46 % du code d’un développeur moyen. À mesure que les contributions générées par l’IA ne cessent d’augmenter, il devient essentiel de conserver un historique complet du développement. Les équipes ont besoin de registres clairs indiquant quelles modifications ont été générées par l’IA, lesquelles ont été modifiées par les développeurs, qui les a revues, quels tests ont été effectués et à quel moment le logiciel a été validé pour le déploiement.

Ces informations s’avèrent particulièrement précieuses lorsque les organisations mènent des enquêtes sur des incidents de production, réalisent des audits internes ou répondent aux questions des clients concernant la qualité des logiciels. En l’absence de traces fiables, les équipes d’ingénierie consacrent davantage de temps à reconstituer les décisions prises qu’à résoudre les problèmes.

Une traçabilité rigoureuse favorise également la conformité réglementaire. Les organisations opérant dans le cadre de normes telles que SOC 2, ISO 27001, HIPAA ou PCI DSS doivent démontrer l’efficacité de leurs processus de gestion des changements, de contrôle d’accès, de tests et d’approbation. Le code généré par l’IA ne fait pas l’objet d’un traitement réglementaire différent du simple fait que le logiciel a été généré à l’aide d’une intelligence artificielle. Dans de nombreux cas, les autorités de régulation exigent les mêmes preuves à l’appui des modifications générées par l’IA que celles requises pour le développement logiciel traditionnel.

Les modifications générées par l’IA doivent rester mineures et ciblées. Les messages de commit doivent préciser quelles parties ont été générées par l’IA et lesquelles ont été modifiées manuellement. Certaines organisations ont mis en place des hooks de commit qui ajoutent automatiquement des métadonnées identifiant l’assistant de codage IA utilisé pendant le développement. Ces pratiques permettent de créer un historique de développement plus transparent sans entraîner de charge de travail supplémentaire significative.

Le défi plus large en matière de gouvernance dépasse le cadre de l’ingénierie. Selon BairesDev, 64 % des ingénieurs interrogés ont identifié les préoccupations liées à la confidentialité et à la sécurité des données comme le principal obstacle à l’adoption de l’IA au sein des organisations clientes. 42 % d’entre eux ont par ailleurs mis en avant des politiques d’utilisation de l’IA restrictives ou peu claires. Ces résultats suggèrent que de nombreuses organisations sont encore en train de mettre en place les structures de gouvernance nécessaires pour soutenir l’adoption de l’IA à l’échelle de l’entreprise.

Pour les dirigeants, la traçabilité doit être considérée comme un investissement dans la résilience plutôt que comme une charge administrative. Des processus de développement bien documentés simplifient la mise en conformité, accélèrent les audits, améliorent la gestion des incidents et renforcent la confiance des clients. À mesure que l’IA s’intègre de plus en plus profondément dans l’ingénierie logicielle, les organisations dotées de processus de gouvernance aboutis seront mieux placées pour étendre son utilisation sans accroître les risques opérationnels ou réglementaires.

Les outils d’IA devraient renforcer les processus d’ingénierie existants

La valeur d’un assistant de codage basé sur l’IA dépend moins du modèle lui-même que de sa capacité à s’intégrer aux pratiques existantes d’ingénierie logicielle d’une organisation. Une gouvernance solide donne systématiquement de meilleurs résultats que la simple adoption d’outils plus avancés.

De nombreuses organisations évaluent les plateformes d’IA en fonction de leurs capacités de génération de code, de la qualité des réponses ou de la facilité d’utilisation pour les développeurs. Ces facteurs ont certes leur importance, mais ils ne doivent pas constituer les principaux critères de décision. La question la plus importante est de savoir si l’outil d’IA s’intègre de manière transparente aux processus de révision, aux pipelines de test, aux contrôles de sécurité et aux workflows de déploiement existants.

Le code généré par l’IA doit respecter exactement les mêmes normes d’ingénierie que le code écrit par des humains. Toute modification doit faire l’objet d’une revue de code, de tests automatisés, d’une analyse de sécurité, d’une intégration continue et d’une validation de déploiement avant d’être mise en production. Si un assistant IA parvient à contourner ces contrôles, l’entreprise introduit un risque inutile dans son processus de livraison logicielle.

La normalisation améliore également l’efficacité opérationnelle. L’utilisation d’un trop grand nombre d’assistants de codage basés sur l’IA peut entraîner des flux de travail incohérents, accroître les besoins en formation, compliquer la gouvernance et rendre plus difficile la mise en place de normes d’ingénierie communes à l’ensemble des équipes de développement. Le choix d’un ou deux outils d’IA approuvés permet aux organisations de mettre en place des processus reproductibles tout en réduisant la complexité inutile.

L’intégration revêt une importance tout aussi grande. Les outils d’IA doivent s’interfacer directement avec les systèmes de gestion du code source, les plateformes d’intégration continue, les scanners de sécurité et les flux de travail des développeurs. Cela permet au code généré par l’IA de passer par les contrôles qualité établis sans créer de processus de développement parallèles, plus difficiles à surveiller et à gérer.

Cette approche favorise également une meilleure évaluation. Lorsque les modifications générées par l’IA suivent le même processus que toutes les autres modifications logicielles, les entreprises peuvent comparer la rapidité de livraison, les taux de défauts, les constatations en matière de sécurité, la réussite des déploiements et les coûts de maintenance à l’aide d’indicateurs cohérents. Cette visibilité permet à la direction d’évaluer les investissements dans l’IA sur la base de résultats commerciaux mesurables plutôt que d’hypothèses ou de retours d’expérience ponctuels.

Un agent de programmation basé sur l’IA qui effectue des modifications directement dans une branche de production sans déclencher de révision, de test ou de validation de sécurité ne fait pas preuve d’une capacité avancée. Il met en évidence une faiblesse dans la gouvernance technique de l’organisation.

Pour les dirigeants, cela vient renforcer un principe important : l’IA doit venir renforcer les systèmes qui garantissent déjà la qualité des logiciels, plutôt que d’y créer des exceptions. Les organisations qui intègrent l’IA dans leurs contrôles techniques existants amélioreront leur productivité tout en préservant la fiabilité, la sécurité et la conformité. Celles qui laissent l’IA fonctionner en dehors des cadres de gouvernance établis risquent d’accroître leur dette technique et leur risque opérationnel, quel que soit le niveau d’avancement de la technologie sous-jacente.

Point clé n° 11 : la réussite de la mise en œuvre de l’IA repose sur une ingénierie rigoureuse

L’IA transforme le développement logiciel à un rythme extraordinaire. Les organisations qui en tireront le plus grand bénéfice ne seront pas nécessairement celles qui recourent le plus à l’IA. Ce seront celles qui mettront en place la discipline d’ingénierie la plus solide autour de cette technologie.

On part souvent du principe qu’une utilisation accrue de l’IA se traduit automatiquement par une productivité accrue. L’IA apporte une réelle valeur ajoutée lorsqu’elle s’inscrit dans le cadre de processus d’ingénierie bien établis. Lorsque ces processus sont affaiblis ou ignorés, une génération de code plus rapide entraîne souvent davantage de problèmes de sécurité, des coûts de maintenance plus élevés, une qualité inégale et une dette technique croissante.

Il s’agit en fin de compte d’un défi de gestion plutôt que d’un défi technologique. Les organisations ont besoin de principes opérationnels clairs qui définissent comment l’IA doit être utilisée, dans quels cas le jugement humain est indispensable, comment le code généré est révisé et comment la qualité est vérifiée avant le déploiement. Sans ces normes, les développeurs adopteront naturellement des pratiques différentes, ce qui rendra la qualité des logiciels de plus en plus difficile à gérer d’une équipe à l’autre.

Aucune de ces pratiques ne diminue la valeur de l’IA. Au contraire, elles la renforcent. L’IA donne le meilleur d’elle-même lorsqu’elle évolue dans un environnement qui définit des objectifs clairs, fournit un retour d’information fiable et s’appuie sur une gouvernance cohérente. Une discipline d’ingénierie rigoureuse permet aux organisations de tirer parti des gains de productivité tout en limitant les risques opérationnels et de sécurité inutiles.

Cela modifie également la manière dont les dirigeants doivent évaluer les initiatives en matière d’IA. Le succès ne doit pas être mesuré uniquement à l’aune de la production des développeurs ou de la quantité de code généré. Parmi les indicateurs plus pertinents, on peut citer la qualité des logiciels, la fiabilité du déploiement, les performances en matière de sécurité, la satisfaction client, l’effort de maintenance, la conformité réglementaire et la capacité de l’organisation à maintenir la production dans la durée.

À mesure que les capacités de l’IA continuent de s’améliorer, l’avantage concurrentiel tiendra de plus en plus à la mise en œuvre plutôt qu’à l’accès à la technologie. La plupart des organisations auront accès à des modèles d’IA similaires. Ce qui distinguera les entreprises les plus performantes, c’est la qualité de leurs pratiques d’ingénierie, de leurs cadres de gouvernance et de leur rigueur opérationnelle.

Les dirigeants doivent également prendre conscience que l’adoption de l’IA est un processus continu, et non une mise en œuvre ponctuelle. Les modèles évoluent, les réglementations changent, les menaces de sécurité gagnent en sophistication et les systèmes logiciels ne cessent de gagner en complexité. Les normes d’ingénierie doivent donc être réexaminées régulièrement afin de s’assurer qu’elles restent en adéquation tant avec les avancées technologiques qu’avec les objectifs de l’entreprise.

Le message principal est clair. L’IA doit être considérée comme un puissant accélérateur de productivité, et non comme un substitut au jugement technique. Les organisations qui associent l’IA à une ingénierie logicielle rigoureuse amélioreront simultanément leur rapidité, leur qualité et leur résilience. Celles qui s’appuient sur l’IA sans renforcer leur gouvernance pourront certes progresser plus rapidement au départ, mais elles risquent davantage d’accumuler une dette technique, d’introduire des failles de sécurité évitables et d’augmenter leurs coûts opérationnels à long terme.

Les gagnants à long terme ne se distingueront pas par l’ampleur de leur utilisation de l’IA. Ils se distingueront par leur capacité à intégrer efficacement l’IA au sein d’une culture d’ingénierie rigoureuse, capable de produire systématiquement des logiciels sécurisés, fiables et faciles à maintenir.

En conclusion

L’IA a atteint un stade où la question n’est plus de savoir si votre service d’ingénierie doit l’utiliser. La question est de savoir si votre organisation est prête à bien la gérer.

Les entreprises qui enregistrent les meilleurs résultats ne considèrent pas l’IA comme un raccourci. Elles la considèrent comme une capacité qui s’inscrit dans un cadre de règles claires, de résultats mesurables et de pratiques d’ingénierie rigoureuses. Elles comprennent que la productivité n’a de valeur que lorsqu’elle permet de produire des logiciels sécurisés, fiables et faciles à maintenir.

Pour les dirigeants d’entreprise, cela implique un changement de mentalité. L’IA ne doit pas être évaluée en fonction du nombre de lignes de code qu’elle génère ou de la fréquence à laquelle les développeurs l’utilisent. Elle doit être évaluée en fonction de son impact sur les indicateurs qui comptent pour l’entreprise : une mise en production plus rapide sans augmentation du taux de défauts, une sécurité renforcée sans augmentation du risque opérationnel, des coûts de maintenance réduits, de meilleurs résultats pour les clients et des performances d’ingénierie durables dans le temps.

C’est également une opportunité de faire preuve de leadership. Les organisations qui mettent en place dès aujourd’hui des politiques claires en matière d’IA développeront des cultures d’ingénierie capables de s’adapter à mesure que la technologie continue d’évoluer. Ces politiques doivent définir les domaines dans lesquels l’IA est encouragée, ceux où l’expertise humaine est indispensable, la manière dont le code généré par l’IA est révisé, ainsi que les critères de mesure de la réussite. Lorsque ces attentes sont cohérentes d’une équipe à l’autre, l’IA devient plus facile à déployer à grande échelle et à gérer.

La technologie continuera de progresser. Les modèles gagneront en performances, les outils de développement seront de plus en plus intégrés et l’IA se chargera de tâches de plus en plus complexes. Rien de tout cela ne remet en cause la nécessité d’un jugement technique avisé. Au contraire, cela rend une exécution rigoureuse encore plus importante, car le volume de logiciels générés par l’IA ne cessera d’augmenter.

L’avantage concurrentiel ne viendra pas du simple fait d’avoir accès à l’IA. Cet avantage est en effet à la portée de tous. Il viendra de la mise en place d’une organisation qui sait utiliser l’IA de manière responsable, cohérente et à grande échelle.

L’avenir appartient aux équipes d’ingénieurs qui associent l’IA à une gouvernance rigoureuse, à un leadership avisé et à des normes sans compromis. Ces organisations agiront plus rapidement, développeront de meilleurs logiciels, réduiront les risques inutiles et jetteront les bases qui continueront à générer de la valeur bien après que l’engouement initial pour l’IA se sera estompé.