Ligne de commande et MCP dans les app builders : ce qui change quand le projet sort du navigateur

C'est là qu'interviennent deux pièces qui changent beaucoup le quotidien, et qui séparent aujourd'hui les plateformes : une vraie ligne de commande et un serveur MCP.

Ce qu'une ligne de commande règle et que le navigateur ne règle pas

Trois choses concrètes.

Voir le projet entier d'un coup. À l'écran, la définition de l'application est répartie en onglets : les entités ici, les automatisations là, la configuration de chaque page ailleurs. Sur le disque, c'est un dossier. Vous ouvrez fab.schema.json et vous lisez toutes les entités et tous les champs sur un seul écran, et la recherche de votre éditeur fonctionne par-dessus.

Lancer avant de publier. Une commande qui monte l'application sur votre machine, sur le même gabarit que celui de la publication, donne la boucle courte qui manque quand chaque vérification dépend d'un déploiement.

Automatiser. Dès que la définition est un fichier, elle entre en gestion de versions, en revue par pull request et dans une chaîne d'intégration continue. Cela n'intéresse pas tout le monde, et cela intéresse énormément qui livre des applications à des clients.

Ce qu'un serveur MCP règle

Le MCP est le protocole qui laisse un assistant parler à un outil sans intermédiaire humain. Concrètement, c'est la différence entre ces deux échanges :

« Collez ici le schéma de votre projet pour que je puisse proposer l'automatisation. »

« Je vais lire le schéma et écrire l'automatisation. »

Le second, c'est ce qui se passe quand un serveur MCP tourne avec votre identification. L'assistant appelle l'opération de lecture, reçoit les vraies entités, les vrais champs et les vrais identifiants, et écrit par-dessus.

Et voilà la partie que l'on sous-estime souvent : sans le schéma sous la main, un modèle invente. Un mauvais identifiant de modèle répond 404, un champ inexistant répond 422, et l'assistant passe trois tentatives à corriger ses arguments alors que le problème était de n'avoir rien lu avant d'écrire.

Le détail qui décide de la sécurité : comment la clé naît

Presque toutes les plateformes offrant un accès par terminal règlent l'authentification de la même façon : un écran avec un bouton « générer une clé », une valeur affichée une fois, et un avertissement de la conserver en lieu sûr.

Le problème n'est pas la clé, c'est son trajet. Entre cet écran et votre terminal, elle passe par le presse-papiers, presque toujours par l'historique du shell, parfois par un canal de discussion quand quelqu'un doit configurer la machine d'un autre, et souvent par un fichier de configuration qui finit dans un dépôt.

L'alternative est le flux d'appareil, le même schéma que vous avez déjà utilisé pour autoriser une application sur un téléviseur. Le terminal demande une autorisation, affiche un code court, et ouvre une page où vous vérifiez que le code correspond et approuvez. La clé naît dans la machine qui va s'en servir et n'est affichée nulle part.

Trois conséquences en valent la peine :

• Rien à copier, donc rien à laisser fuir. La clé n'existe à aucun moment sous une forme affichable.
• La permission est demandée sur le moment. Une machine qui n'a qu'à consulter demande la lecture, et son identification ne voit même pas les opérations d'écriture. Un assistant qui ne voit pas un outil ne l'essaie pas et ne brûle pas des tours à lire un 403 comme une erreur d'argument.
• La révocation est du bon côté. Se déconnecter sur une machine y oublie l'identification. Révoquer dans le panneau fait tomber cette machine côté serveur, ce dont vous avez besoin quand le portable a disparu.

Où l'identification vit ensuite

Dans le trousseau du système, quand il y en a un. Sinon, dans un fichier aux permissions restreintes, et il vaut la peine d'exiger que l'outil dise qu'il en est arrivé là. Un outil qui choisit le moins bon endroit en silence apprend à l'utilisateur à supposer qu'il est toujours au meilleur.

Ce qui reste hors du terminal, volontairement

Deux choses, et le partage est délibéré :

Les identifiants d'intégration. Les fichiers décrivant ce que le projet a connecté doivent être en lecture seule : ils disent qu'une intégration existe et quelles opérations appeler, pour qu'un assistant puisse travailler, et jamais le secret lui-même. Connecter et renouveler se fait sur la plateforme.

Supprimer. Un fichier disparu de votre dossier ne devrait pas disparaître de l'application. Votre copie locale peut être en retard, l'IA a pu modifier le projet sur la plateforme entre-temps, et supprimer là-bas à cause d'une absence ici détruit du travail. Le bon comportement est de signaler la différence et de vous laisser la décision.

Comment évaluer cela sur une plateforme

Si vous comparez des outils et que ce type d'accès compte, cinq questions les séparent vite :

1. La clé est-elle copiée, ou naît-elle par flux d'appareil ?
2. Peut-on demander la lecture seule ?
3. La révocation vaut-elle pour le serveur, ou oublie-t-elle seulement la clé sur la machine ?
4. Le serveur MCP expose-t-il la lecture du schéma, ou seulement des opérations d'écriture ?
5. Que fait la commande de publication d'un fichier qui a disparu ?

Les réponses en disent plus sur la maturité de l'outil que la liste des commandes.

Chez Fabapp

La ligne de commande fait login par flux d'appareil, range l'identification dans le trousseau, accepte --scopes "read" pour une machine qui ne fait que consulter, et rapporte la définition du projet avec pull. dev lance l'application en local sur le gabarit de publication, et deploy publie. Le serveur MCP utilise l'identification déjà rangée par le login et respecte sa permission : un jeton de lecture ne liste pas les outils d'écriture.

Les machines connectées se trouvent dans Profil, sous Clés et CLI, avec la permission de chacune et sa dernière utilisation. La révocation est immédiate et vaut pour le serveur.