Outils contre compétences contre MCP : les trois niveaux d’un agent IA
Les outils exposent les actions, les compétences codent les flux de travail, et le standard MCP normalise les connexions externes. Un modèle mental clair pour concevoir des architectures d’agents sans mélanger les différentes couches.
Comprendre les éléments de base des agents d’IA
Le paysage des agents évolue constamment.
Les débats précédents portaient principalement sur la rédaction de prompts, les modèles fondamentaux et les pipelines de récupération. Les conceptions actuelles exigent que les agents interagissent avec des API, gèrent des workflows, consultent des bases de données, travaillent sur des codes sources et communiquent avec des solutions SaaS.
Trois catégories dominent ces conceptions :
Outils. Compétences. MCP.
Catégories apparentées, tâches distinctes.
Des frontières claires rendent les architectures plus faciles à concevoir et à discuter.
Le modèle mental simple
Une comparaison concise aide avant d’aborder les détails :
| Concept | Primary purpose | Simple question |
| ---------- | ------------------------------------------------ | ----------------------------------------- |
| **Tools** | Give the agent capabilities/access | *What can the agent access or do?* |
| **Skills** | Give the agent instructions/workflows | *How should the agent perform a task?* |
| **MCP** | Standardize connections to external capabilities | *How can the agent connect to a service?* |
Ou, encore plus brièvement :
Les outils permettent d’exécuter des opérations. Les compétences guident la stratégie. MCP relie les systèmes externes.
Le reste de cet article décrit en détail chaque niveau.
- Qu’est-ce que les outils ?
outil est une surface d’opération que l’agent peut utiliser pour modifier ou lire quelque chose. La simple génération de texte ne suffit pas ; lorsque le travail nécessite un effet secondaire, le modèle sélectionne un outil.
Imaginez un assistant de codage disposant d’opérations telles que :
readFile()
writeFile()
runTests()
searchCode()
runCommand()
Le modèle peut en conclure :
Je dois examiner ce fichier.
Puis il invoque :
readFile("lib/features/login/login.dart")
L’outil s’exécute et renvoie son résultat au modèle.
Les outils peuvent se connecter à des systèmes internes
Dans une entreprise, les outils peuvent accéder à :
- Des services HTTP privés
- Des bases de données
- Des pipelines de construction et de déploiement
- Des outils de suivi des tickets comme Jira
- Des hébergeurs de contrôle de version
- Des stacks d’observabilité
- Des plateformes de déploiement et de mise en production
- Des bases de connaissances
Exemples :
getEmployeeDetails()
createJiraTicket()
triggerBuild()
checkDeploymentStatus()
queryCustomer()
La partie importante
Les outils développés en interne signifient généralement que vous gérez l’intégration.
Vous devrez assumer la responsabilité de :
- L’implémentation
- L’authentification
- L’autorisation
- La sécurité
- Gestion des erreurs
- Surveillance
- Entretien
- Gestion des versions
Ces outils sont puissants, mais ils génèrent également une charge technique continue.
2. Qu’est-ce qu’une compétence ?
Les compétences répondent à une question différente.
compétence correspond à une formation : elle montre à l’agent une procédure ou un flux de travail concret.
Pensez à des guides réutilisables plutôt qu’à des API brutes.
Supposons qu’une compétence s’appelle :
releaseFlutterApp
Elle pourrait décrire des étapes telles que :
1. Check the current version.
2. Verify the changelog.
3. Run unit tests.
4. Run static analysis.
5. Build the release artifact.
6. Upload to the testing environment.
7. Verify the deployment.
8. Generate the release summary.
Une compétence n’a pas besoin de fournir des capacités brutes. Elle indique à l’agent comment combiner les capacités disponibles pour atteindre un objectif. Cette distinction est importante.
En d’autres termes : un outil annonce une opération disponible ; une compétence précise la séquence préférée pour accomplir une tâche.
3. Les compétences ne sont pas des intégrations
La confusion commence souvent ici.
Supposons qu’un agent dispose déjà de :
runCommand()
readFile()
writeFile()
searchCode()
Ces éléments constituent des capacités.
Maintenant, associez-y une compétence :
Flutter Release Workflow
Cette compétence peut orienter l’agent vers :
read project configuration
↓
run tests
↓
run analyzer
↓
build application
↓
verify artifact
↓
prepare release
Les compétences possèdent des connaissances en orchestration. Elles encodent le manuel de procédure.
En bref :
Outil = ce qui peut être exécuté
Compétence = comment le sequencer
4. Qu’est-ce que MCP ?
La troisième couche est le MCP (Model Context Protocol).
Celui-ci standardise la manière dont les applications d’IA se connectent aux systèmes externes et aux serveurs de fonctionnalités.
Au lieu d’adaptateurs spécifiques pour chaque paire de produits, MCP propose un protocole commun permettant d’offrir des fonctionnalités aux clients.
Une structure simplifiée se présente comme suit :
AI Application
│
│ MCP
▼
MCP Server
/ | \
/ | \
▼ ▼ ▼
GitHub DB Jira
L’application d’IA communique avec un serveur MCP ; ce serveur met à disposition des fonctionnalités provenant d’un service externe.
GitHub
PostgreSQL
Slack
Jira
Google Drive
Internal APIs
La superficie exacte des interfaces dépend du serveur.
- Pourquoi MCP est important
En l’absence d’un protocole commun, les équipes avaient tendance à créer des adaptateurs sur mesure pour chaque application d’IA et chaque interface SaaS.
Cette approche conduit à :
AI Agent
│
├── Custom GitHub integration
├── Custom Jira integration
├── Custom Slack integration
├── Custom Database integration
└── Custom Internal API integration
Plus de services signifie plus d’adaptateurs personnalisés.
Un protocole commun fournit un modèle de communication unique.
Conceptuellement :
AI Client
│
MCP
│
┌─────────┴─────────┐
│ │
MCP Server MCP Server
│ │
GitHub Database
Le client d’IA et l’implémentation du service restent plus distincts l’un de l’autre.
6. Outils vs Compétences vs MCP
Une vue côte à côte qui reste utile lors des revues de conception :
| | Tools | Skills | MCP |
| ------------------ | -------------------- | ------------------------ | ---------------------------------------- |
| Main purpose | Provide capabilities | Provide procedures | Standardize external connections |
| Focus | **Action** | **Instructions** | **Integration protocol** |
| Answers | "What can I do?" | "How should I do it?" | "How do I connect?" |
| Example | `run_tests()` | Flutter release workflow | GitHub MCP server |
| Usually created by | Developers | Developers/teams | Service/integration providers |
| Maintenance | You may own it | You own the instructions | Often handled by the MCP server/provider |
Les systèmes réels brouillent les frontières, mais le modèle mental reste utile pour concevoir des agents.
7. Un exemple pratique : le développement Flutter assisté par l’IA
Fondez le modèle avec un assistant d’équipe Flutter.
La demande souhaitée de l’utilisateur pourrait être :
« Préparez l’application pour la prochaine version de test. »
L’agent pourrait mettre à disposition plusieurs outils :
read_file()
search_code()
run_flutter_test()
run_flutter_analyze()
build_android()
upload_to_firebase()
Puis définir une compétence :
Flutter QA Release
La compétence pourrait indiquer :
1. Check the current branch.
2. Read pubspec.yaml.
3. Determine the current version.
4. Run flutter analyze.
5. Run tests.
6. Build the QA APK.
7. Upload the APK.
8. Verify the upload.
9. Generate a release summary.
Une connexion MCP pourrait alors accéder à un hébergeur Git, à des tickets, à une base de données, ou à n’importe quel serveur MCP publié par l’équipe.
La forme finale pourrait être :
AI Agent
│
┌────────────┼────────────┐
│ │ │
Skills Tools MCP
│ │ │
▼ ▼ ▼
QA Release Flutter CLI External
Workflow Build/Test Services
L’agent cesse alors d’être un bot Q&A.
Il peut interpréter un objectif, suivre un manuel opérationnel, utiliser des outils locaux et interagir avec des systèmes externes.
C’est avec cette stack que le travail sur des produits agents devient réellement concret.
8. Une autre façon de se souvenir de la différence
Imaginez l’intégration d’un nouvel ingénieur.
Les outils sont leur équipement
Laptop
Terminal
Git
Database
CI/CD
APIs
L’équipement permet de mener à bien des actions.
Les compétences sont leurs connaissances
How to release an app
How to debug a production issue
How to investigate a crash
How to review Flutter code
How to troubleshoot CI/CD
Les connaissances expliquent comment effectuer le travail.
MCP est la couche de connexion normalisée
C’est le canal cohérent permettant à l’application IA d’accéder aux systèmes externes qui publient des capacités MCP.
9. Pourquoi cette distinction est importante pour les développeurs
Les concepteurs qui confondent ces trois couches créent involontairement de la complexité.
Un cycle plus simple :
Étape 1 — Identifier la capacité
Demandez :
« Que doit être capable de faire l’agent ? »
Cette réponse constitue un candidat pour une Outil.
Étape 2 — Identifier le flux de travail
Demandez :
« Comment l’agent doit-il accomplir cette tâche ? »
Cette réponse constitue un candidat pour une Compétence.
Étape 3 — Identifier les systèmes externes
Demandez :
« Est-ce que cela nécessite un accès à un service externe ? »
Si oui, une intégration basée sur MCP pourrait convenir.
10. La vue d’ensemble
Le schéma commun consiste à passer de :
Prompt
↓
LLM
↓
Response
à des layouts plus similaires à :
┌───────────────┐
│ AI Agent │
└───────┬───────┘
│
┌─────────────┼─────────────┐
│ │ │
Skills Tools MCP
│ │ │
▼ ▼ ▼
Workflows Actions External
Services
Ensemble, ils incitent les systèmes à passer de la production de texte à l’exécution de tâches structurées.
Pour les organisations d’ingénierie, c’est là le changement significatif.
Conclusion finale
Rappelez-vous ce trio de cette manière : les outils déclenchent des actions, les compétences codent les stratégies de jeu, et MCP standardise la manière dont les systèmes externes s’attachent.
Ils ne se substituent pas les uns aux autres.
Un design durable les combine généralement : les compétences décrivent la stratégie, les outils exécutent les étapes, et MCP peut fournir un pont uniforme vers des systèmes tiers.
Cet ensemble de termes gagne en valeur à mesure que les produits sortent du simple chat pour entreprendre des tâches d’ingénierie agente.