Un article publié sur le GitHub Blog examine cinq hypothèses répandues concernant l’utilisation de l’intelligence artificielle dans le développement logiciel, notamment l’idée que le code généré n’a pas besoin d’être lu, que le RAG est dépassé et que les Skills ont rendu le Model Context Protocol (MCP) inutile. Selon l’auteur, l’intérêt de ces affirmations ne réside pas dans leur formulation abrégée, mais dans l’examen de leurs conditions et de leurs limites lorsqu’elles sont appliquées au travail réel.
La responsabilité du code ne revient pas au modèle
La règle fondamentale avancée par l’article est que le développeur doit examiner le code jusqu’à être capable d’expliquer le résultat et d’en assumer la responsabilité. Cela ne signifie pas qu’il faille vérifier chaque ligne avec la même profondeur : une modification d’un système d’authentification en production mérite une revue différente de celle d’une simple expérience en CSS.
La revue peut commencer avant même que l’agent n’écrive du code, en comprenant l’implémentation existante, en déterminant les dépendances et les cas limites, et en établissant un plan. Dans d’autres cas, le code produit nécessite un examen direct de la gestion des erreurs, des autorisations, de l’accès aux données, des performances, de l’accessibilité et des tests. Selon l’article, l’intelligence artificielle déplace l’effort, mais ne supprime pas le travail lui-même.
La compétence la plus importante est le discernement
L’article rejette l’idée que les entreprises ne recruteront pas les personnes qui n’utilisent absolument pas l’intelligence artificielle, tout en reconnaissant qu’un nombre croissant d’équipes demandent aux candidats comment ils utilisent ces outils. Le signal le plus important, selon cette analyse, n’est pas l’enthousiasme pour l’outil en soi, mais la capacité à expliquer quand le développeur l’utilise et quand il travaille manuellement, comment il examine ses résultats et comment il équilibre rapidité, qualité, sécurité et maintenabilité.
Éviter l’intelligence artificielle peut devenir un obstacle dans une entreprise qui développe ses produits ou s’appuie fortement sur elle, mais une dépendance totale n’est pas une meilleure solution. Il faut maintenir l’humain dans la boucle et disposer d’une explication claire de ce à quoi le développeur fait confiance et de ce à quoi il ne fait pas confiance.
MCP, Skills et RAG : des rôles complémentaires
L’article établit une distinction entre les trois outils. MCP fournit une méthode standardisée permettant aux agents d’accéder aux outils et aux données et de les appeler, tandis que les Skills fournissent des connaissances structurées sur la manière de travailler de l’équipe, les règles de modification du projet ou les conventions suivies. Comme les Skills sont souvent rédigées au format Markdown, leur lisibilité pour les humains fait partie de leur utilité.
Le RAG, ou génération augmentée par récupération, apporte au système des informations pertinentes situées en dehors des données d’entraînement du modèle, telles que la documentation, l’historique du support, les détails des produits, les connaissances internes et le contexte de la base de code. Une bonne récupération aide le modèle à commencer à travailler à partir d’un contexte plus proche de la réponse, tout en réduisant l’espace de recherche et le risque de fournir une réponse incomplète.
L’auteur ne considère donc pas que les Skills ont tué MCP ou que le RAG est mort : l’agent peut utiliser MCP pour accéder à un outil, suivre un Skill pour appliquer des instructions propres au projet et recourir à la récupération pour obtenir le contexte nécessaire. Opposer ces composants revient à ignorer la manière dont ils peuvent s’intégrer dans un même flux de travail.
La maintenabilité face à un nouveau test
L’article examine également l’idée que la nécessité d’entraîner le modèle sur une base de code donnée signifie forcément que le code est mauvais. Il existe des raisons légitimes de recourir à un entraînement personnalisé, mais l’incapacité du modèle à comprendre la base de code peut révéler un problème auquel un nouveau collègue serait également confronté.
Une architecture claire, une nomenclature cohérente, des tests lisibles, des abstractions utiles et une documentation à jour rendent le code plus facile à comprendre, aussi bien pour les agents que pour les humains. La lecture éditoriale proposée ici est que les outils d’intelligence artificielle ne dispensent pas les équipes des pratiques d’ingénierie logicielle ; ils peuvent au contraire rendre les défauts de maintenabilité plus visibles.
Du débat à l’expérimentation
L’article s’achève en appelant à tester les opinions dans la pratique plutôt qu’à remplacer chaque opinion par son contraire. Il cite le projet Pollinations AI, dans lequel les contributeurs peuvent gagner des crédits appelés pollen en améliorant le projet, ainsi que le projet Avian Visitors, qui documente un écran à encre électronique écoutant les oiseaux et transformant leurs visites en tableaux changeants à l’aide d’un microphone, d’un Raspberry Pi, de composants imprimés en 3D et d’images générées.
Ces projets ne tranchent pas tous les débats sur l’intelligence artificielle, mais ils produisent des éléments concrets et révèlent les compromis. La principale limite du contenu est qu’il propose un cadre général d’orientation et des exemples, et non des résultats de mesures comparatives démontrant la supériorité d’un flux de travail précis. Il convient donc de considérer ses recommandations comme des points de test pour la pratique, et non comme des règles définitives.