Code, RAG, Skills, MCP : quatre questions pour garder la main sur un agent

Faut-il encore lire le code produit par une IA ? Le RAG est-il devenu inutile ? Les Skills ont-ils rendu MCP obsolète ? Ces questions, reprises dans un épisode du GitHub Podcast présenté par GitHub le 18 septembre 2026, mélangent en réalité trois problèmes différents : vérifier un résultat, fournir des connaissances et autoriser une action.

La réponse utile n’est donc pas un classement de technologies. Elle consiste à regarder ce que l’agent doit faire, ce que l’équipe doit pouvoir contrôler et quelle preuve reste disponible après son intervention. Un agent peut disposer d’un contexte riche et d’outils bien connectés tout en produisant un changement que personne ne sait défendre en revue.

1. Lire le code reste une activité de vérification

La question « faut-il lire le code ? » suppose souvent que l’IA aurait remplacé la revue humaine. Ce n’est pas le bon cadre. La lecture du code ne sert pas seulement à repérer une faute de syntaxe ou un bug évident. Elle permet de vérifier le périmètre du changement, ses hypothèses et ses effets secondaires.

Un diff peut être techniquement cohérent et pourtant modifier un contrat implicite, supprimer une validation, élargir une permission ou rendre un comportement plus difficile à observer. Même lorsque l’agent explique son choix, cette explication ne constitue pas une preuve suffisante. Elle doit être confrontée au code, aux critères d’acceptation et aux tests qui couvrent réellement le comportement attendu.

La revue peut toutefois changer de forme. Il n’est pas nécessaire de relire chaque ligne avec la même intensité. Une équipe peut concentrer son attention sur les frontières sensibles :

• les entrées et sorties d’une fonction ou d’une API ;
• les permissions, secrets et appels réseau ;
• les migrations et changements de données ;
• les erreurs, retours arrière et comportements par défaut ;
• les zones que les tests ne couvrent pas.

Lire le code n’est donc pas un geste nostalgique. C’est le contrôle qui relie la proposition de l’agent au comportement que l’équipe accepte de livrer. Pour un correctif complexe, cette vérification gagne à être accompagnée d’une preuve comportementale, d’un test ciblé ou d’une fixture isolée. Notre méthode de validation d’un correctif généré par IA avant le merge suit précisément cette logique : ne pas confondre un résultat qui paraît propre avec un résultat démontré.

2. Le RAG ne disparaît pas : son rôle doit être correctement délimité

Dire que le RAG est « mort » revient à demander à un mécanisme de connaissance de résoudre un problème d’exécution. Le RAG peut aider un agent à retrouver une convention, une décision d’architecture, une procédure ou un extrait documentaire. Il ne garantit pas que l’agent a compris la priorité entre deux documents, ni qu’il est autorisé à modifier le système concerné.

La vraie question devient : quelle information doit être récupérée à la demande, et quelle règle doit rester stable et visible ? Une consigne de sécurité ou une contrainte de livraison ne devrait pas dépendre uniquement du fait qu’un moteur de recherche retrouve le bon paragraphe. À l’inverse, une documentation qui change régulièrement n’a pas intérêt à être copiée en permanence dans des instructions statiques.

On peut distinguer quatre fonctions :

Cette séparation évite deux erreurs. La première consiste à charger toutes les informations dans un prompt permanent, au risque de créer un contexte lourd et difficile à maintenir. La seconde consiste à croire qu’une réponse bien documentée autorise automatiquement l’action suivante. La récupération d’un document apporte une connaissance ; elle ne donne pas nécessairement un droit d’agir.

3. Skills et MCP ne se remplacent pas sur le même axe

Le titre de la discussion pose une alternative volontairement provocatrice : « les Skills ont-ils tué MCP ? » Pour analyser cette opposition sans slogan, il faut d’abord regarder la responsabilité portée par chaque élément. Un Skill peut être compris comme une manière d’organiser une capacité, une procédure ou un savoir-faire réutilisable. MCP renvoie, lui, à la question de la connexion entre un agent et des outils ou des données.

Ces deux idées peuvent donc se compléter. Une compétence bien décrite peut expliquer quand utiliser une capacité, quelles entrées fournir et quels contrôles demander. Une connexion d’outils peut fournir l’accès technique à une donnée ou à une action. Confondre les deux revient à croire qu’une procédure documentée équivaut à une permission exécutable.

Pour une équipe de développement, la distinction opérationnelle tient en trois questions :

1. Que sait faire l’agent sans appeler de système externe ?
2. Quelles informations doit-il lire pour décider correctement ?
3. Quelles actions externes peut-il réellement demander, et qui les valide ?

Une capacité utile doit préciser son périmètre, ses préconditions, ses limites et son résultat attendu. L’outil connecté doit, de son côté, appliquer ses propres contrôles côté serveur. Décrire une action comme « lecture seule » dans une instruction ne suffit pas si l’interface réelle permet d’écrire, de supprimer ou de déclencher un traitement durable.

Cette distinction rejoint les questions d’architecture déjà posées par les équipes qui évaluent la sécurité d’un déploiement MCP avant de connecter un agent aux outils. Le sujet n’est pas de choisir l’acronyme le plus récent, mais de séparer découverte, autorisation, exécution et preuve.

4. Une méthode en cinq étapes avant de changer de pile

Avant de remplacer un dispositif par un autre, il est préférable de décrire le workflow réel. Cette méthode ne demande pas de benchmark imaginaire ni de classement général des outils.

1. Décrire la sortie attendue. S’agit-il d’un résumé, d’un plan, d’un diff, d’une décision ou d’une action dans un système externe ?
2. Classer le contexte. Séparez les règles stables, les connaissances évolutives et l’état qui doit être lu au moment de l’exécution.
3. Limiter les capacités. Commencez par la lecture lorsque l’écriture n’est pas indispensable. Définissez les ressources, commandes et données accessibles.
4. Définir la preuve. Précisez ce qui permettra de vérifier le résultat : diff, test, sortie structurée, journal d’action, capture d’état ou approbation humaine.
5. Prévoir l’arrêt. Un agent doit pouvoir s’arrêter lorsque le périmètre s’élargit, qu’une permission est ambiguë ou qu’une preuve manque.

Cette chronologie est plus robuste qu’un changement de technologie décidé à partir d’une démonstration. Elle permet aussi de constater qu’un même workflow peut combiner une instruction courte, une recherche documentaire, une compétence procédurale et un outil limité. La question n’est pas de maximiser le nombre de composants, mais de rendre leur rôle lisible.

Checklist avant de déclarer une technologie dépassée

• Le besoin initial concerne-t-il la connaissance, la procédure ou l’action ?
• Le système sait-il distinguer une information retrouvée d’une permission d’agir ?
• Les versions, sources ou états consultés sont-ils identifiables ?
• Le changement produit est-il vérifiable sans faire confiance à l’explication de l’agent ?
• Les actions irréversibles exigent-elles une validation explicite ?
• Une équipe peut-elle interrompre le workflow et reprendre la main ?
• Le dispositif choisi réduit-il réellement le contexte inutile et les accès superflus ?

À ce stade, les trois formules du titre cessent d’être des verdicts. Oui, il faut encore lire le code lorsque la responsabilité porte sur le comportement livré. Non, le RAG n’est pas automatiquement obsolète : il répond à la récupération de connaissances, pas à la validation d’une action. Et non, une nouvelle façon de regrouper des capacités ne rend pas inutile une interface d’outils ; elle peut seulement déplacer la manière de la décrire et de la contrôler.

La bonne architecture est celle qui laisse une trace compréhensible entre l’intention, le contexte, l’action et la preuve. C’est cette continuité, plus que le nom de la technologie, qui permet à une équipe de développeurs de garder la main.