Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Le fait que tout le monde soit bientôt licencié à cause de l'IA peut sembler une plaisanterie pour certains, mais c'est une réalité inquiétante contre laquelle se battent de nombreux développeurs. Alors que nous nous dirigeons vers l'avenir, l'IA n'écrit plus de code, elle remplace les codeurs.
Satya Nadella de Microsoft a récemment déclaré que près de 30 % du code de Microsoft est désormais écrit par des outils d'IA tels que Copilot. Quelques jours à peine après que cette statistique ait été rendue publique, le coup de massue est arrivé : Microsoft a licencié 2 000 employés. S'agit-il d'une coïncidence ou existe-t-il un lien entre le fait que 30 % du code soit écrit par l'IA et le licenciement d'employés ?
De telles coïncidences ne sont pas uniquement liées à Microsoft. Un phénomène similaire peut être observé chez CloudStrike, IBM et d'autres. Même Goldman Sachs prédit que jusqu'à 300 millions d'emplois seront remplacés par l'IA dans un secteur qui manquait de près de deux millions d'ingénieurs il y a quelques années.
Ce n'est pas la première fois que le monde de la technologie panique à l'idée d'une disparition d'emploi.
Qu'il s'agisse des bytecodes Java ou de la migration vers le cloud, les développeurs ont toujours été confrontés au scepticisme, à la peur et à la résistance lors de l'émergence de nouvelles technologies. Mais cette fois, c'est différent. Pourquoi ?
Car, cette fois, nous avons affaire à des outils qui ne se contentent pas d'automatiser, mais qui génèrent des résultats imprévisibles. Ces outils sont hallucinants. Ils sont peut-être rapides, mais ils ne sont pas fiables. Malgré cela, on leur fait confiance pour générer du code au niveau de la production.
Dans cet article, nous explorons cette tension et examinons pourquoi ce que l'on appelle la chaîne d'intégrité de l'intention pourrait être notre meilleure option pour survivre à l'IA sans en perdre le contrôle. C'est parti !
Panique et progrès - Le cycle continue
La panique entourant l'IA dans le développement de logiciels peut sembler nouvelle, mais ce n'est pas le cas. En fait, chaque abstraction dans la technologie, qu'il s'agisse de Java, de l'utilisation d'outils SaaS ou du passage au nuage, s'accompagne toujours de doutes.
Il fut un temps où les ingénieurs remettaient en question le bytecode Java, se demandant s'il était fiable. D'autres jugeaient l'informatique en nuage trop risquée pour les données sensibles. La résistance a toujours existé, mais malgré cela, chaque changement qui a prévalu jusqu'à présent a aidé les développeurs à construire mieux qu'avant.
Au fil du temps, les abstractions ont constitué l'épine dorsale de l'évolutivité, conduisant au développement de systèmes plus rapides, plus complexes et plus résistants. Mais ce qui rend le moment actuel différent, c'est la nature de l'IA. Les abstractions traditionnelles visaient davantage à simplifier les complexités tout en maintenant un comportement cohérent et reproductible. Cependant, les progrès tels que les modèles de langage à grande échelle (LLM) laissent la place à l'aléatoire.
Les LLM sont conçus pour être basés sur des probabilités, ce qui signifie que les résultats de ces modèles peuvent être différents même s'ils sont alimentés par des entrées identiques. Cette imprévisibilité est un point de rupture avec l'abstraction passée.
Si les outils du passé ont suscité des craintes et des résistances, ils étaient accompagnés d'un cadre qui pouvait être déterminé. Avec les LLM, les développeurs travaillent désormais avec des systèmes qui se comportent différemment à chaque fois, ce qui signifie qu'ils doivent relever de nouveaux défis en matière de précision et de fiabilité des logiciels générés par ces modèles.
Les LLM ne sont-ils qu'un singe doté d'un GPU ?
Malgré leur popularité, les LLM restent peu fiables lorsqu'il s'agit de développer des logiciels. Leurs capacités de génération de code ressemblent plus à des efforts d'essai et d'erreur qu'au travail d'un ingénieur.
Plutôt qu'un outil précis et intelligent, vous pouvez considérer un LLM comme un singe équipé d'un GPU qui essaie des choses jusqu'à ce qu'elles fonctionnent.
Comment cette réalité se traduit-elle dans la vie réelle ? Il existe de nombreux exemples de ces modèles qui inventent simplement des fonctions, fabriquent des noms de paquets et produisent même une logique dangereusement erronée.
Par exemple, les LLM ont référencé des bibliothèques npm qui n'existent pas, et des acteurs malveillants ont utilisé ces noms hallucinés pour enregistrer des paquets, introduisant ainsi un nouveau vecteur d'attaques de la chaîne d'approvisionnement.
Nombreux sont ceux qui considèrent que ce risque n'existe qu'en théorie, mais ce n'est pas le cas. Les études qui comparent les résultats en matière de qualité du code des principaux outils tels que GitHub Copilot, Amazon CodeWhisperer et ChatGPT génèrent du code correct seulement dans 31 % à 65 % des cas, ce qui signifie que le code est défectueux près de la moitié du temps.
Ce qui est encore plus grave, c'est que 40 % du code de l'IA était vulnérablecar il contenait des failles exploitables et ne respectait pas les pratiques de sécurité de base.
En y regardant de plus près, il est clair que le problème ne se limite pas aux inexactitudes. Il s'agit également d'une confiance mal placée. Ces outils présentent leur code avec un degré élevé de certitude, même dans les cas où les résultats sont erronés.
Il est arrivé que des développeurs demandent à l'IA d'optimiser leur code pour le rendre plus rapide. Résultat ? Le modèle supprime les contrôles de validation ou interrompt complètement la couverture des tests au nom de la performance.
Dans ces conditions, nous pouvons dire que les LLM ne remplacent pas les humains, du moins pas pour l'instant. Ce sont des outils qui peuvent toutefois amplifier l'intention et les capacités de ceux qui les utilisent. Cela dit, ces modèles manquent d'une solide compréhension des systèmes et du contexte ; on ne peut pas leur faire confiance aveuglément, et le jugement humain est aujourd'hui plus crucial que jamais.
La chaîne d'intégrité de l'intention
Compte tenu de tout ce que nous avons abordé jusqu'à présent, il est clair que le fait de s'appuyer sur un code généré par l'IA s'accompagne d'un ensemble de risques évolutifs. La chaîne d'intégrité de l'intention est un cadre conçu pour garantir que ces risques ne prévalent pas et que l'idée originale d'un développeur soit transformée en un logiciel fonctionnel et fiable.
Le concept fondamental de ce cadre est que quelque chose se perd entre l'idée d'un développeur et le résultat final, et c'est ce que l'on appelle un écart de traduction. Ces écarts existent entre une invite et le résultat final produit par un modèle LLM. Cela est dû au fait que le comportement du modèle est imprévisible et basé sur l'improvisation, ce qui signifie qu'il n'y a aucune garantie que ce qui sort reflète ce qui est entré.
La chaîne d'intégrité de l'intention peut aider à résoudre ce problème grâce à un processus en plusieurs étapes centré sur quatre artefacts :
- Prompt - Rédigée par des humains, elle représente l'intention brute ou la fonctionnalité souhaitée.
- Spec - Version structurée et normalisée de l'invite, toujours en langage naturel, mais formatée pour plus de clarté et de cohérence.
- Test - Générés automatiquement à partir de la spécification, ces tests définissent ce qu'est un comportement correct.
- Code - Généré par le LLM, destiné à passer les tests basés sur la spécification.
Avant d'aller de l'avant, il est essentiel de savoir que chaque artefact est un maillon de la chaîne, mais qu'il ne faut pas lui accorder une confiance aveugle.
Bien que l'invite n'ait pas besoin d'être validée puisqu'elle n'est qu'un point de départ, la spécification doit être examinée par des humains pour s'assurer qu'elle capture l'intention de l'invite. De même, le test doit être verrouillé et vérifiable, et le code généré par LLM ne doit être validé que s'il réussit le test verrouillé.
Cette structure introduit des points de contrôle à chaque étape, ce qui peut contribuer à réduire le risque de failles de sécurité et de caractéristiques hallucinées, en garantissant que le résultat correspond à l'intention humaine.
Confiance, vérification, promptitude
Le code généré par l'IA devient de plus en plus courant. Dans ce contexte, la mise en place de garde-fous n'est pas une question de bonnes pratiques, c'est une question de survie.
Sans contraintes clairement définies comme les spécifications et les tests, les LLM peuvent générer des logiciels peu sûrs ou carrément cassés. En outre, des techniques telles que le développement piloté par les tests (TDD) et le développement piloté par le comportement (BDD) fournissent une structure à un stade précoce, mais elles ont eu du mal à être adoptées parce que les développeurs ont tendance à écrire du code plutôt que des tests.
Le développement et l'IA devenant désormais plus qu'une tendance, la compétence la plus critique que les développeurs peuvent acquérir est l'articulation des intentions.
Cela signifie que les développeurs doivent désormais se transformer en ingénieurs prompts à exprimer des exigences de manière précise, à concevoir des spécifications testables et à vérifier les résultats du LLM pour y déceler des défauts. Dans ces conditions, le leadership technique consiste aujourd'hui davantage à avoir la capacité de guider un modèle par le biais d'une sollicitation structurée et d'une validation des contraintes.
Une compréhension commune et un ensemble de compétences à l'épreuve du temps
L'utilisation de spécifications structurées comme Gherkin peut contribuer à limiter les malentendus entre les humains et les machines. Bien que ces spécifications ne soient pas du code, elles sont suffisamment formelles pour être comprises par les humains et les machines.
Si le fait de travailler avec des spécifications pour tester puis coder peut contribuer à limiter les erreurs d'intelligence artificielle dans le résultat final, il faut pour cela que les développeurs changent d'état d'esprit.
Ils doivent cesser de considérer les LLM comme des experts et les considérer comme un outil destiné à amplifier l'intention. Cependant, si l'intention initiale est mauvaise, le résultat du code le sera également.
Dans cette optique, les développeurs doivent se concentrer sur l'amélioration de leurs performances pour être prêts pour l'avenir, notamment en rédigeant de meilleurs messages-guides, en validant les résultats et en concevant des spécifications claires. Ceux qui développent ces trois compétences clés peuvent avoir une meilleure chance d'être efficaces dans leur carrière. Ceux qui ne le font pas risquent d'être remplacés par l'IA.
Réflexions finales
L'IA a changé et continue de changer le développement de logiciels d'une manière que nous n'avons jamais vue auparavant. Bien qu'elle puisse coder de manière plus rapide et plus efficace, son résultat n'est pas toujours conforme aux attentes ou contient des failles logiques, des vulnérabilités exploitables, des politiques de sécurité mal configurées et bien d'autres choses encore.
Les développeurs peuvent toutefois utiliser la chaîne d'intégrité de l'intention pour garder le contrôle et s'assurer que le code de l'IA est généré comme prévu en alignant l'intention humaine sur le résultat de la machine par le biais de la structure et de la validation.
