MCP, ACP ou skills d’IA : choisir la bonne connexion
Distingue endpoints de modèles, outils MCP, agents ACP, skills réutilisables et tâches planifiées à partir de cas concrets.
Tu veux qu’un assistant lise un ticket, corrige un bug ou répète une vérification chaque semaine. « Ajouter une intégration » ne te dit pas de quelle configuration tu as besoin. Les endpoints de modèles, MCP, ACP, les skills et les planifications gèrent chacun une partie différente du travail.
Pars de l’action voulue et cherche ce qui manque. Ajouter un protocole ne t’apporte pas un meilleur modèle, ne te connecte pas à un compte et ne garde pas un ordinateur allumé. Ce guide t’aide à choisir la plus petite configuration qui fonctionne, dans Mono by Reunified ou une app similaire.
1. Identifie la capacité manquante
Utilise ce tableau avant de chercher un plugin :
| Objectif immédiat | Ce qu’il faut vérifier d’abord |
|---|---|
| Utiliser un autre modèle pour les réponses texte | Réglages de l’endpoint du modèle |
| Lire ou modifier des informations dans un autre service | Un serveur MCP adapté ou une intégration intégrée |
| Travailler avec un agent de code sur un dépôt | Si le client et l’agent ACP fonctionnent ensemble |
| Réutiliser un workflow tout prêt | Un skill et ce dont il a besoin |
| Répéter une action qui fonctionne déjà | Un planificateur et l’endroit où il tourne |
Ce sont des points de départ, et ils fonctionnent souvent ensemble. Un skill peut utiliser MCP, un agent de code peut appeler des outils et une tâche planifiée peut lancer un skill. Trouve la première pièce manquante au lieu d’installer toutes les couches.
2. Utilise MCP pour une capacité de service
Model Context Protocol (MCP) relie une app d’IA aux fonctions qu’un serveur propose. L’architecture officielle les classe en outils, ressources et prompts. Un serveur peut en proposer un ou plusieurs.
Imagine que tu veux lister les tickets ouverts d’un service de gestion de projet. Il te faut une connexion qui propose cette recherche et un compte autorisé à lire le projet. Un serveur capable de chercher des tickets ne sait pas forcément en créer ou en fermer.
Vérifie ce que le serveur sait vraiment faire et teste-le avec une petite requête en lecture seule. Pour la mise en place, utilise le guide de connexion MCP. Changer de modèle de langage ne lui donne pas accès à ton compte de projet.
3. Utilise ACP pour une session de programmation
Agent Client Protocol (ACP) définit comment un agent de code échange avec un client, comme un éditeur. L’introduction ACP l’explique. L’agent fait le travail dans le dépôt ; le client est l’écran depuis lequel tu le diriges.
Pour « trouve et corrige ce test qui échoue », vérifie que l’agent, le client et l’ordinateur qui les fait tourner fonctionnent ensemble. Utiliser le même protocole ne prouve pas qu’ils ont été testés ensemble. Le dépôt et les commandes ont toujours besoin d’un ordinateur avec les bons accès et les bons outils installés.
Un téléphone peut piloter ce travail sans être l’ordinateur qui l’exécute. Dans Mono Code, ton ordinateur héberge les projets et ton téléphone pilote des agents comme Claude Code, Gemini CLI ou OpenCode via ACP. Notre guide de programmation à distance couvre les petites tâches, les validations et la reconnexion. ACP ne te donne pas un ordinateur cloud toujours allumé et ne règle pas la facture du fournisseur de l’agent.
4. Utilise un skill pour un comportement réutilisable
« Skill » ne veut pas dire la même chose d’un produit à l’autre. Dans Mono, un skill est un module complémentaire qui peut inclure des modules, des paramètres et des connexions à d’autres services. Ailleurs, un skill peut être un document d’instructions ou un paquet d’un autre format. Ne suppose pas que les skills d’un produit marcheront dans un autre.
Pour « mettre ces notes au même format chaque semaine », regarde d’abord ce que le skill attend en entrée et ce qu’il renvoie. Il peut n’utiliser que le texte que tu lui donnes, appeler un modèle ou récupérer des informations via une connexion. Chacun de ces cas ajoute de la configuration et une chose de plus qui peut échouer.
Utilise la liste d’installation des skills pour vérifier ce dont un skill a besoin et tester un résultat. Une installation réussie ne prouve pas que sa source de données marche aujourd’hui, ni qu’il tourne sur tous les appareils.
5. Ajoute l’horaire après validation de l’action
Un planificateur décide quand le travail commence. Il n’apporte ni les données ni les autorisations qui manquent. Pour un résumé hebdomadaire de projet, vérifie d’abord à la main que tu obtiens les bons éléments et un résumé utile. Ensuite, décide où la tâche peut tourner à l’heure voulue.
Les Tâches de Mono tournent sur ton appareil, et une tâche manquée pendant que l’app était fermée est rattrapée la prochaine fois que tu l’ouvres. Ne compte donc pas sur une tâche à l’heure pile pendant que ton téléphone est éteint. Une tâche qui a besoin d’une commande de bureau a aussi besoin de cet ordinateur ; une planification ne déplace pas la commande sur ton téléphone.
Quand un résultat planifié manque, vérifie où la tâche tourne avant de changer de modèle. Quand un service renvoie une erreur d’autorisation, vérifie la connexion du compte avant de réinstaller l’agent de code.
6. Décris ta configuration en cinq lignes
Écris cinq lignes : modèle, services externes, actions réutilisables, ordinateur de programmation (s’il y en a un) et planification (s’il y en a une). Laisse vides les lignes inutiles. À côté de chaque partie utilisée, note qui la gère, quelles informations elle reçoit et qui te la facture.
Une simple tâche d’écriture peut ne demander qu’un modèle. Réparer un dépôt peut demander un agent ACP et un ordinateur, sans nouvelle connexion MCP. Un récapitulatif hebdomadaire d’un service peut demander une connexion, un skill et un planificateur qui tourne.
Mono n’est pas encore disponible, mais tu peux rejoindre la liste d’attente. En attendant, utilise cette carte pour prévoir une configuration que tu sais expliquer et tester avant de l’agrandir.
