Connecter votre IA à un projet

Vous voulez que Claude Code, Claude Desktop ou Cursor vous aide à éditer un projet Sovrium local. Rien n'est déployé, il n'y a aucun serveur à monter, et aucune clé à émettre.

C'est le chemin local. Pour laisser un assistant lire et manipuler les données d'une application déployée en HTTP, voir plutôt Connecter Claude à Sovrium via MCP : celui-là exige un bloc d'authentification et une clé d'API, et expose un jeu d'outils entièrement différent.

Ce que l'assistant obtient

Votre assistant exécute le binaire Sovrium sur votre machine et lui parle sur un tube. Quatre outils en lecture reviennent :

• Lire votre configuration, chaque secret déclaré remplacé par un marqueur.
• La vérifier, et récupérer exactement ce à quoi Sovrium a objecté.
• Consulter ce qu'un réglage accepte, pour qu'il écrive quelque chose de valide du premier coup.
• Voir si votre application tourne, et si la dernière sauvegarde a été appliquée.

Ces quatre-là sont des lectures, et ils sont tout ce que vous obtenez tant que vous n'en décidez pas autrement. L'assistant peut malgré tout modifier votre application en éditant le fichier de configuration dans le dossier, comme il édite n'importe quel autre fichier : Sovrium remarque la sauvegarde et recharge de lui-même. Ce que l'étape suivante ajoute, c'est de le lui laisser faire par la connexion, là où Sovrium peut d'abord contrôler la modification.

Le diriger vers le dossier

Il vous faut le chemin du dossier de projet et une ligne de configuration côté client. Claude Code la prend comme une commande :

claude mcp add sovrium -- sovrium mcp --project ~/apps/crm

Le -- est obligatoire : tout ce qui le suit constitue la commande du serveur, transmise telle quelle. Ajoutez --scope project pour écrire l'entrée dans un .mcp.json partagé à la racine du projet plutôt que dans vos propres réglages.

Claude Desktop et Cursor prennent la même chose sous forme de bloc, dans claude_desktop_config.json pour le premier et dans .cursor/mcp.json (ou ~/.cursor/mcp.json) pour le second :

{
  "mcpServers": {
    "sovrium": {
      "command": "sovrium",
      "args": ["mcp", "--project", "/Users/moi/apps/crm"]
    }
  }
}

Redémarrez le client ensuite. Nommez toujours le répertoire : sans lui, le processus lit le répertoire de travail, et quand c'est un client qui l'a lancé, ce répertoire relève de son choix et non du vôtre.

Vous utilisez l'application Sovrium ? Son écran Connecter votre IA affiche le même extrait avec le vrai chemin de votre projet déjà rempli, et un bouton qui le copie. C'est la même commande : l'écran existe pour que personne n'ait à saisir un chemin à la main.

Activer l'écriture

Facultatif, et désactivé jusqu'à ce que vous le fassiez. Ajoutez une variable d'environnement au bloc que vous venez d'écrire :

{
  "mcpServers": {
    "sovrium": {
      "command": "sovrium",
      "args": ["mcp", "--project", "/Users/moi/apps/crm"],
      "env": { "MCP_CONFIG_WRITE": "1" }
    }
  }
}

Redémarrez le client. L'assistant peut désormais énumérer les fichiers dont votre configuration est faite, en lire un, en remplacer un, et annuler sa dernière modification. Il lui faut aussi que le dossier soit nommé explicitement, ce que le bloc ci-dessus fait déjà : une session retombée sur le répertoire de travail n'obtient que les lectures.

L'écriture est encadrée plutôt que confiée, et vous n'en configurez rien. Les modifications restent dans le dossier et ne touchent que des fichiers .yaml, .yml et .json, jamais votre .env, votre .git/ ni le répertoire de données de Sovrium. Un fichier qui a changé sur le disque depuis que l'assistant l'a lu est refusé plutôt qu'écrasé : une sauvegarde faite dans votre propre éditeur ne peut donc pas être perdue au profit d'une modification qu'il réfléchissait encore. Une modification qui ne se décoderait pas comme une configuration valide n'atteint jamais le disque. Supprimer une colonne exige votre accord explicite, que l'assistant ne peut pas donner à votre place. Et chaque changement est précédé d'un instantané, si bien qu'il y a toujours un chemin de retour.

Votre configuration en MCP énumère les outils et chaque raison pour laquelle une écriture est refusée.

Le vérifier

Demandez à l'assistant quelles tables votre application déclare. Il appelle l'outil de lecture et répond à partir de votre configuration réelle.

À la main, le serveur est un tube, et printf suffit :

printf '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"0"}}}\n' \
  | sovrium mcp --project ~/apps/crm

La poignée de main revient sur la sortie standard ; la ligne qui nomme le fichier de configuration trouvé est sur la sortie d'erreur. Cette séparation est le contrat : détournez la sortie d'erreur et il ne reste sur la sortie standard que du JSON-RPC valide, rien d'autre.

S'il ne se connecte pas

• Aucun outil dans le client. Les outils portent le nom de votre application : une configuration dont le name vaut crm donne crm_config_read et trois voisins. Une liste vide signifie que le client n'a jamais lancé le processus ; vérifiez que la commande est dans le PATH du client.
• Un constat de configuration manquante au lieu de votre configuration. Le processus tourne, dirigé vers un dossier qui ne contient ni app.yaml, ni app.yml, ni app.ts. Le constat nomme l'option qui corrige cela.
• Le client signale un échec de protocole. Le serveur répond aux deux révisions du protocole et décide d'après le message d'ouverture : ce n'est donc pas quelque chose à configurer. Un moteur plus ancien, qui ne répond pas du tout à la commande, en est la cause la plus probable.

Ensuite

• Votre configuration en MCP — chaque outil, ce qu'il renvoie, et l'ordre de résolution.
• L'application Sovrium — la fenêtre, et où vit un projet.
• Validation et schéma — les mêmes constats depuis la ligne de commande.