L’illusion de la productivité grâce à l’IA

Les outils d’IA peuvent donner une fausse impression d’amélioration de la productivité

Les outils d’IA pour le codage sont rapides. Cela ne fait aucun doute. Ils vous donnent du code instantanément. Il a l’air solide. Il se compile. Tout le monde a l’impression d’avancer rapidement. Mais les sentiments et les faits sont deux choses très différentes.

Les tests contrôlés réels racontent une histoire différente. Au début de cette année, METR, Model Evaluation and Threat Research, a mené une étude randomisée auprès de développeurs expérimentés de logiciels libres. Le groupe a été divisé. La moitié d’entre eux avait accès à des outils d’IA, l’autre moitié n’y avait pas accès. Les développeurs utilisant l’IA pensaient coder 20 % plus vite. En réalité, ils codaient 19 % plus lentement. Ils étaient en fait 19 % plus lents.

Cela représente un écart de 39 points entre la perception et la réalité. Et cela ne se produit pas parce que ces développeurs manquent d’expérience, mais parce que le code généré par l’IA semble correct. Jusqu’à ce qu’il ne le soit pas. Il peut utiliser des bibliothèques obsolètes ou appeler des paramètres qui n’existent pas. Pire encore, il peut introduire des conditions de course ou des failles de sécurité silencieuses qui ne sont détectées que plus tard, lorsque le mal est déjà fait.

C’est là que le coût entre en jeu. L’IA vous fournit du code à un coût marginal proche de zéro. Mais pour pouvoir compter sur ce code, vous avez toujours besoin d’humains pour l’analyser, le vérifier et le sécuriser. Il ne s’agit pas d’un « avantage », mais d’un chemin critique. Le rapport 2024 GenAI Code Security Report de Veracode le montre clairement : 45 % des échantillons générés par l’IA présentaient des failles de sécurité classées dans la liste des 10 principales failles de l’OWASP. Il ne s’agit pas seulement de fautes de frappe. Il s’agit de de vulnérabilités d’injection SQLde contrôles d’autorisation défaillants, de choses qui peuvent faire tomber des systèmes entiers.

Ainsi, si la sensation de vitesse est attrayante, elle devient un problème lorsque les décideurs la confondent avec la productivité réelle. Il ne s’agit pas d’être lent. Il s’agit de ne pas être imprudent. Le problème de la plupart des équipes n’est pas le manque d’accès à l’IA. C’est de penser qu’elles peuvent sauter l’étape de la vérification tout en continuant à « aller vite ». Ce n’est pas le cas.

Si vous voulez de la rapidité, vous avez toujours besoin de contrôle. On ne fait pas évoluer un processus de développement en acceptant aveuglément les résultats de l’IA. Vous le faites en embauchant des humains qui peuvent vérifier ses suggestions et appliquer des normes de qualité aussi rapidement que le code est livré. Toute autre solution revient à jouer avec un risque que vous ne pouvez pas vous permettre.

À l’ère de l’IA, la compétence clé est l’ingénierie de la vérification.

Utiliser l’IA pour écrire du code n’est pas le véritable défi. N’importe qui peut demander à un chatbot de générer une fonction. La véritable valeur est de savoir si cette fonction est correcte, sécurisée et maintenable. C’est ce qu’on appelle l’ingénierie de la vérification. Et dans un monde où l’IA est omniprésente, elle devient la compétence centrale qui définit les équipes d’ingénieurs.

La plupart des développeurs pensent encore que la mesure de leur travail est la quantité de code qu’ils produisent. C’était logique avant l’IA générative. Aujourd’hui, le volume n’a plus d’importance. L’IA peut générer plus de lignes de code en cinq minutes qu’un humain en cinq jours. Ce qui compte, c’est de savoir si ce code fait ce qu’il est censé faire, et s’il le fait en toute sécurité. S’il échoue silencieusement, s’il génère des vulnérabilités ou s’il crée une complexité à long terme, c’est un handicap, pas un atout.

Cette évolution est déjà visible chez les développeurs performants. Les meilleurs d’entre eux ne se contentent pas de solliciter l’IA. Ils créent des environnements dans lesquels les résultats sont testés, examinés et vérifiés par défaut. Ils utilisent des « chemins d’or », des modèles sécurisés et pré-examinés qui précisent ce que les outils d’IA sont autorisés à générer. Elles enveloppent l’IA dans des pipelines de tests continus, de modélisation des menaces, d’analyse statique et de contrôles d’exécution pour s’assurer que rien de dangereux ne se glisse dans les mailles du filet. Il ne s’agit pas de frais généraux. C’est de la responsabilité.

Andrej Karpathy, l’un des fondateurs d’OpenAI et ancien responsable de l’IA chez Tesla, a récemment déclaré qu’il pourrait être « 10 fois plus puissant » en utilisant les outils actuels, à condition de les combiner « correctement ». Le mot clé est « correctement ». Il s’agit de faire le travail que la plupart des gens ignorent. Il peut le faire parce qu’il comprend parfaitement quand l’IA est susceptible de se tromper. Il dispose d’un système de reconnaissance des schémas issu d’années d’écriture et de correction de codes. Ce n’est pas le cas de la plupart des gens. Sans une validation appropriée, les outils d’IA inondent les systèmes d’hypothèses inexactes, ce qui entraîne des dysfonctionnements ultérieurs à grande échelle.

Marlene Mhangami, Developer Advocate chez Microsoft, a bien résumé la situation : « Le goulot d’étranglement reste la livraison d’un code dont vous pouvez assurer la maintenance et dans lequel vous pouvez avoir confiance ». C’est là que la courbe de productivité réelle s’infléchit vers le haut. Non pas lorsque le codage devient plus rapide, mais lorsque la confiance dans la stabilité à long terme du code augmente en même temps.

Les dirigeants de C-suite doivent comprendre qu’aujourd’hui, la mise à l’échelle du développement ne signifie pas l’embauche de développeurs supplémentaires ou l’ajout d’outils d’IA. Il s’agit d’embaucher des ingénieurs capables de vérifier les résultats à la même vitesse qu’ils sont générés. La vérification est la couche de contrôle dont nous avons besoin pour faire confiance à l’IA. Sans elle, l’échelle devient un chaos. Avec elle, l’échelle devient durable.

L’intégration hâtive de l’IA sans vérification rigoureuse entraîne une dette technique

Il n’y a pas d’intérêt à aller vite si le code que vous déployez doit être retravaillé de manière significative par la suite. C’est ce qui se passe actuellement avec de nombreuses équipes de développement qui adoptent trop rapidement des outils d’IA, en supposant que ces systèmes sont suffisamment fiables pour qu’on leur fasse confiance sans poser de questions. Ce n’est pas le cas. En l’absence de processus de révision et de validation stricts, le code généré par l’IA ajoute une complexité à long terme qui devient coûteuse à corriger.

Il s’agit de la dette technique, dont l’IA accélère l’accumulation. Elle y parvient en poussant les développeurs dans une boucle de production plus rapide où chaque version introduit de nouvelles inconnues. Il ne s’agit pas seulement de bogues, mais aussi de défauts de conception, de lacunes de sécurité et d’intégrations mal comprises qui s’accumulent et rendent les développements futurs plus difficiles et plus lents, et non plus rapides. Les équipes qui fonctionnent sans contrôle rigoureux peuvent atteindre les premières mesures de vélocité, mais elles finiront par crouler sous le poids d’une maintenance qu’elles n’ont pas planifiée.

Il ne s’agit pas de spéculations. Le rapport 2024 GenAI Code Security Report de Veracode a révélé que près de la moitié (45 %) des échantillons de code générés par l’IA contenaient des vulnérabilités graves, notamment celles figurant dans le Top 10 de l’OWASP, comme l’injection SQL et le contrôle d’accès non respecté. Il ne s’agit pas d’erreurs mineures. Il s’agit de failles exploitables qui peuvent permettre à des attaquants d’accéder à des systèmes sensibles ou à des données clients.

SonarSource a mis en garde contre cette tendance. Il la décrit comme l’émergence de bases de code « en écriture seule », produites si rapidement et avec une telle incohérence que les équipes humaines peuvent à peine les auditer, les comprendre ou les étendre. Ces systèmes deviennent résistants au changement, fragiles lors des mises à jour et risqués à exploiter. La vitesse de production dépasse la largeur de bande des équipes chargées du nettoyage, ce qui signifie que l’intégrité du produit diminue alors même que la production augmente.

Pour les équipes dirigeantes, le signal est clair. L’intégration de l’IA doit être mise en œuvre avec un modèle de gouvernance tourné vers l’avenir. Les équipes ont besoin de barrières de qualité automatisées, évolutives et appliquées. Si vous gagnez du temps maintenant mais que vous compromettez la fiabilité du système, vous ne gagnez rien, vous ne faites que reporter le risque. La productivité est réelle lorsque le développement rapide est associé à une structure qui maintient la qualité du code à un niveau élevé à chaque étape du processus.

L’adoption efficace de l’IA nécessite une approche systémique

Le déploiement d’outils d’IA dans le développement de logiciels ne consiste pas simplement à connecter un IDE à un chatbot. C’est une mise en œuvre trop superficielle. Si votre objectif est d’obtenir des performances réelles à grande échelle, l’approche doit être systématique. Cela signifie qu’il faut penser au-delà de l’outil lui-même et construire la bonne structure autour de lui, la sécurité, les tests, l’auditabilité et les mécanismes de contrôle qui garantissent que les résultats sont fiables.

Les entreprises qui obtiennent des résultats significatifs grâce au développement assisté par l’IA ne se contentent pas de simples messages-guides. Elles conçoivent des environnements avec des attentes précises. Entrées normalisées. Des architectures prédéfinies. Vérification automatique. Des chemins d’or, des modèles rigides qui dictent exactement comment l’IA doit produire du code dans des limites sûres. Ces garde-fous limitent le hasard et renforcent la qualité, rendant chaque contribution de l’IA prévisible et sûre.

Le reste est de l’ordre de l’infrastructure. Linting, SAST, DAST, tests de régression, tous regroupés dans des pipelines qui vérifient en permanence le travail produit par l’IA. Il s’agit d’une approche de bout en bout qui réduit les fenêtres d’échec et détecte l’instabilité avant qu’elle n’entre en production. Ces systèmes ne fonctionnent pas seulement plus rapidement, ils fonctionnent avec clarté. Chaque modification apportée par l’IA est validée ou rejetée en fonction de règles définies. Pas d’ambiguïté. Pas de confiance aveugle.

Simon Willison, un développeur respecté de logiciels libres, a inventé le terme « évaluation basée sur les vibrations » pour décrire les personnes qui acceptent le code principalement parce qu’il « semble correct ». C’est exactement le risque auquel s’exposent les équipes qui n’intègrent pas la vérification automatisée dans leurs flux de travail. Cela crée un sentiment de confiance qui n’est pas étayé par des éléments concrets. Cette approche n’est pas évolutive. Elle crée de la fragilité.

Si vous devez prendre des décisions de leadership concernant l’adoption de l’IA, voici ce qui compte : une réflexion au niveau du système. Ne cherchez pas à obtenir des résultats à court terme. Construisez une infrastructure qui canalise l’IA grâce à des garanties de qualité. Créez des politiques de codage sécurisées. Investissez dans des portes de test automatisées. Formez les équipes à traiter l’IA non pas comme une autorité, mais comme un collaborateur rapide dont le travail doit toujours être revu.

Les développeurs qui sont à la pointe dans ce domaine ne seront pas ceux qui demanderont à l’IA d’en faire plus. Ce sont eux qui fixeront les conditions pour que ce que produit l’IA s’aligne sur les normes d’ingénierie. C’est de là que vient l’effet de levier, le contrôle structuré au niveau du système.

Principaux enseignements pour les dirigeants

• L’illusion de la productivité de l’IA : Le code généré par l’IA semble plus rapide mais ajoute souvent des frictions. Les dirigeants devraient mesurer l’impact de l’ingénierie en fonction du résultat de la vérification a posteriori, et non de la vitesse perçue.
• La vérification plutôt que le volume : La compétence critique dans le développement de l’ère de l’IA est la validation, et non la génération de code. Donnez la priorité à l’embauche et à la formation d’ingénieurs capables de vérifier et de contrôler les résultats de l’IA à grande échelle.
• Accélération de la dette technique : L’adoption rapide de l’IA sans surveillance aggrave les risques à long terme. Les dirigeants doivent investir très tôt dans des contrôles de qualité automatisés et des cadres de développement sécurisés afin d’éviter de multiplier les retouches et de s’exposer au risque.
• Mise en œuvre au niveau du système : L’utilisation efficace de l’IA dépend de processus structurés et non d’une expérimentation libre. Intégrez l’application de la loi dans la pile, le contrôle de la qualité, les tests et les modèles sécurisés, afin d’exploiter l’IA en toute sécurité et de manière cohérente.