Outils internes : penser pour humains et agents IA

Quand l'agent IA devient un utilisateur à part entière

Pendant longtemps, un outil interne avait un seul public : les collaborateurs. Un script d'automatisation, un utilitaire de déploiement ou une interface de saisie dans un CRM étaient pensés pour une personne assise devant un écran, capable de lire un menu, de cliquer, de deviner où se placer et de corriger une erreur à la volée.

Ce modèle évolue. Les agents IA, ces programmes capables d'enchaîner des actions de façon autonome, commencent à manipuler les mêmes outils que vos équipes. Et ils n'ont pas les mêmes réflexes qu'un humain.

C'est précisément l'expérience que raconte l'équipe d'ingénierie de Mistral AI dans un article intitulé « Spaces: A CLI Built for Humans and Agents », publié le 31 mars 2026 sur son blog. L'outil décrit, Spaces, a été conçu par Lorenzo Signoretti, Riwa Hoteit et Sam Fenwick. Il s'agit d'un outil en ligne de commande (CLI) interne destiné à aider les équipes à créer des projets, lancer des environnements de développement, générer des fichiers de configuration et déployer des applications.

Chez comm.it, ce retour d'expérience nous parle directement, car il touche au cœur de nos métiers : l'automatisation des processus, l'intégration de l'IA et le développement de logiciels cœur de métier comme les CRM et les ERP. Plutôt que de résumer cet article, nous vous proposons d'en tirer des enseignements concrets pour les entreprises que nous accompagnons.

Le constat : un outil pensé pour l'humain peut bloquer une machine

L'anecdote centrale du récit de Mistral AI est simple. L'équipe avait développé un joli menu interactif pour sélectionner les modules d'un nouveau projet. Visuellement réussi, il fonctionnait parfaitement pour un développeur. Puis un agent a essayé de l'utiliser… et s'est retrouvé face à des codes d'affichage illisibles, sans pouvoir naviguer avec les flèches du clavier ni cocher des options. L'agent était tout simplement bloqué.

La correction immédiate consistait à ajouter une option permettant de passer la sélection directement en paramètre. Mais la leçon retenue par les auteurs va bien au-delà : chaque question posée à l'utilisateur est en réalité une donnée dont le programme a besoin. On peut obtenir cette donnée par une interface interactive, par un paramètre ou par un fichier de configuration. L'important est de penser d'abord à l'information, ensuite seulement à la manière de la saisir.

Ce que cela signifie pour une PME

Transposons ce principe à votre quotidien. Combien de vos processus reposent sur une étape où quelqu'un doit « remplir un formulaire », « cliquer sur valider » ou « choisir dans une liste » ? Dans un CRM, un ERP, un outil de facturation ou un portail fournisseur, ces étapes sont souvent les goulots d'étranglement qui empêchent une automatisation de bout en bout.

Lorsque comm.it conçoit ou fait évoluer un logiciel métier, nous appliquons cette même logique :

• identifier les données réellement nécessaires à chaque action (création d'un client, validation d'un devis, déclenchement d'une commande) ;
• séparer la logique métier de l'interface : la règle de calcul d'une remise ne doit pas dépendre du fait qu'elle soit saisie par un commercial ou transmise par un automate ;
• proposer plusieurs portes d'entrée vers la même logique : écran pour les équipes, API pour les intégrations, import de fichiers pour les traitements en masse.

Comme le résument les ingénieurs de Mistral AI : plusieurs chemins de saisie, un seul chemin d'exécution. La logique ne sait pas comment les informations sont arrivées, et on ne la teste qu'une seule fois.

Le mode « sans intervention » : un contrat clair

L'article insiste sur une option particulière, qui permet d'exécuter une commande sans aucune interaction. Ce n'est pas un simple « passer les confirmations ». C'est un contrat : l'appelant fournit toutes les informations de manière programmatique, et l'outil ne doit jamais rester en attente d'une réponse. Si une donnée manque et qu'aucune valeur par défaut raisonnable n'existe, l'outil doit échouer clairement plutôt que de rester bloqué.

Ce point est fondamental pour toute automatisation fiable. Un processus qui se fige silencieusement en attendant une confirmation que personne ne donnera est l'un des pires scénarios en production : la tâche n'est ni réalisée, ni signalée en erreur.

Dans nos projets d'automatisation des processus métier, nous veillons à ce que chaque traitement automatique :

• dispose de valeurs par défaut documentées pour les paramètres non critiques ;
• s'arrête explicitement avec un message compréhensible lorsqu'une information indispensable fait défaut ;
• remonte ses erreurs vers un canal de supervision (messagerie, tableau de bord, alerte) pour qu'un humain puisse intervenir rapidement.

C'est la différence entre une automatisation qui inspire confiance et une automatisation que l'on finit par surveiller manuellement, ce qui annule une bonne partie de son intérêt.

Un exemple parlant : d'une demande unique à une mise en production

L'équipe illustre ses principes par un cas concret. Les démonstrations interactives intégrées à l'article ont été développées dans un dépôt de code vierge. Un agent a ensuite été chargé de raccorder ce projet à l'outil pour le déployer. Il a commencé par consulter l'aide intégrée des différentes commandes, en a déduit les fichiers de configuration nécessaires, les a générés, a configuré le déploiement et mis en place la chaîne d'intégration continue. Selon les auteurs, le passage d'une demande unique à un déploiement en ligne a pris moins de dix minutes, un délai qu'ils cherchent encore à réduire.

Ce qui a rendu cela possible, c'est que chaque saisie interactive avait un équivalent en paramètre. L'agent a pu travailler en autonomie du début à la fin.

Pour une entreprise, le message est clair : un agent IA n'est efficace que si l'environnement dans lequel il évolue est lisible et pilotable par une machine. L'IA ne compense pas un outil mal conçu ; elle amplifie au contraire les forces et les faiblesses de votre système d'information.

Les données structurées comme interface

Autre enseignement majeur : la place des données structurées. Les applications construites par les équipes de Mistral AI ne se ressemblent pas toutes. Certaines nécessitent une base vectorielle, d'autres une base relationnelle et une interface web, d'autres encore ne sont que des services de traitement en arrière-plan. Plutôt que de coder en dur chaque type de module, l'équipe a mis en place un système de plugins où chaque composant décrit lui-même ses propriétés.

Ces plugins sont introspectables : on peut les lister, les sérialiser, les comparer. Un humain les parcourt dans un menu visuel ; un agent interroge un registre et reçoit une réponse au format JSON. Mêmes données, rendu différent.

Effet secondaire inattendu, selon l'article : ajouter un nouveau type de module, qui imposait auparavant de modifier plusieurs fichiers et générateurs, se résume désormais à écrire une seule classe. Le registre est devenu la source unique de vérité.

Application aux CRM et ERP

Cette notion de source unique de vérité est au cœur de nos projets de logiciels métier. Dans beaucoup de PME, la même information (un catalogue produit, une fiche client, une grille tarifaire) existe en plusieurs exemplaires : dans un tableur, dans le CRM, dans l'outil de facturation, dans la tête d'un collaborateur. Chaque copie diverge avec le temps.

Quand comm.it développe ou intègre un CRM ou un ERP, nous cherchons à :

• modéliser les objets métier (clients, produits, contrats, interventions) comme des données décrites et interrogeables, pas comme des écrans figés ;
• exposer ces données de façon structurée pour que les automatisations, les tableaux de bord et les agents IA puissent les consommer sans retraitement ;
• centraliser les règles pour qu'une évolution (nouveau type de produit, nouvelle étape de validation) se fasse à un seul endroit.

Le bénéfice est double : vos équipes gagnent en cohérence, et vos futurs agents IA disposent d'une base fiable sur laquelle s'appuyer.

Le contexte, carburant des agents IA

L'article reprend un vieil adage : le contenu est roi. Avec les agents, c'est le contexte qui l'est. L'action jugée la plus efficace par l'équipe a été de générer automatiquement deux fichiers à chaque création de projet :

• un fichier de contexte structuré, qui décrit les modules présents, les ports utilisés, les commandes à lancer et les variables d'environnement nécessaires ;
• un fichier de consignes destiné aux modèles de langage, rédigé de façon impérative : non pas « ce projet utilise telle base de données », mais « lance telle commande avant de tester une modification de la base ».

Selon les auteurs, un agent qui lit ces fichiers avant d'agir commet beaucoup moins d'erreurs : il ne devine pas les numéros de port, n'exécute pas la mauvaise commande de test et n'installe pas des dépendances déjà gérées. Et comme le fichier de contexte se met à jour automatiquement, l'agent travaille toujours sur un état à jour.

Documenter pour l'humain… et pour la machine

C'est un point que nous constatons régulièrement chez nos clients : la documentation est souvent le parent pauvre du système d'information. Elle existe dans des courriels, des notes éparses ou la mémoire d'un prestataire. Or, à l'heure de l'IA, une documentation structurée devient un actif stratégique.

comm.it accompagne les entreprises pour :

• formaliser les procédures (déploiement, sauvegarde, création d'un compte utilisateur, configuration d'un poste) sous une forme exploitable par des humains comme par des automates ;
• décrire l'infrastructure (réseau, Wi-Fi, serveurs, services de messagerie, vidéosurveillance) dans des référentiels à jour plutôt que dans des schémas oubliés ;
• préparer des consignes précises pour les assistants et agents IA que vous déployez, afin qu'ils agissent dans un cadre maîtrisé.

Un agent IA bien informé est un agent plus sûr. C'est aussi un excellent moyen de réduire la dépendance à une seule personne qui « sait comment ça marche ».

L'état implicite, ennemi de l'automatisation

Le problème le plus subtil rencontré par l'équipe concernait l'état implicite. Une commande lisait son fichier de configuration dans le dossier courant. Un humain se place naturellement dans le bon dossier ; un agent qui travaille depuis la racine de l'espace de travail n'a aucune raison de le savoir.

La règle retenue : toute hypothèse cachée (dossier courant, variables d'environnement, fichiers de configuration personnels) est un piège pour un agent. Des paramètres explicites, assortis de valeurs de repli raisonnables, résolvent le problème pour les agents et facilitent aussi l'écriture de scripts par les humains.

Dans votre système d'information

L'état implicite ne concerne pas que les développeurs. On le retrouve partout :

• un traitement qui ne fonctionne que lorsqu'il est lancé depuis le poste d'un collaborateur précis ;
• une connexion réseau qui suppose qu'un lecteur partagé est monté ;
• un export qui dépend d'un filtre enregistré dans la session d'un utilisateur ;
• une règle de pare-feu ajoutée « temporairement » et jamais documentée.

Lors de nos audits d'infrastructure et de nos projets d'automatisation, nous traquons ces dépendances invisibles. Les rendre explicites, c'est rendre vos processus reproductibles, transférables et automatisables, que l'exécutant soit un collaborateur, un script planifié ou un agent IA.

La checklist, traduite pour les entreprises

L'article se conclut par une liste de principes que l'équipe résume ainsi : chaque saisie interactive a un équivalent en paramètre, chaque paramètre a une valeur par défaut pour le mode sans interface, l'état est explicite, les plugins sont des modèles de données introspectables, et des fichiers de contexte décrivent le projet de manière structurée.

Voici comment nous traduisons ces principes pour les TPE et PME que nous accompagnons :

1. Chaque action métier doit être accessible autrement que par un clic : API, import, déclencheur automatique.
2. Chaque traitement automatique doit avoir un comportement par défaut connu, et échouer de manière visible quand il ne peut pas conclure.
3. Aucune dépendance cachée : postes, chemins, comptes et droits nécessaires sont documentés et paramétrés.
4. Les objets métier sont des données structurées, partagées par tous les outils, avec une source unique de vérité.
5. Le contexte est formalisé : procédures, architecture et consignes sont rédigées pour être lues aussi bien par vos équipes que par vos agents IA.

Une meilleure conception pour tout le monde

Le point le plus intéressant du témoignage est peut-être sa conclusion : rien de tout cela n'a dégradé l'expérience des utilisateurs humains. Le menu visuel fonctionne toujours, les indicateurs de progression aussi. L'équipe a simplement ajouté une seconde porte. Et cette seconde porte s'est révélée essentielle, non parce que les agents comptent davantage que les humains, mais parce que leurs contraintes sont exactement celles qui rendent un outil composable, scriptable et testable.

Les auteurs posent une question que toute entreprise devrait se poser : et si l'utilisateur à l'autre bout était un processus plutôt qu'une personne ? Quelle que soit la réponse, se la poser améliore l'outil.

Pour une PME, cette question est une opportunité. Il n'est pas nécessaire de tout reconstruire ni de créer une infrastructure spécifique pour l'IA. Il s'agit plutôt de revoir progressivement vos outils, vos processus et votre documentation avec ce double regard. Chaque amélioration profite immédiatement à vos équipes, tout en préparant le terrain pour des agents IA réellement utiles.

Comment comm.it vous accompagne

Notre approche combine plusieurs expertises complémentaires :

• Audit de vos processus et outils : nous identifions les étapes manuelles, les dépendances implicites et les données dispersées qui freinent l'automatisation.
• Développement de logiciels métier : CRM, ERP et outils internes conçus avec une logique centralisée, des API ouvertes et des données structurées.
• Automatisation des processus : enchaînements fiables, supervisés, avec gestion explicite des erreurs.
• Intégration de l'IA : déploiement d'assistants et d'agents encadrés par un contexte clair et des consignes précises.
• Infrastructure et réseau : un socle documenté et maîtrisé (réseau, Wi-Fi, messagerie, vidéosurveillance) sur lequel vos automatisations peuvent s'appuyer en confiance.

L'objectif n'est pas d'ajouter de l'IA pour le principe, mais de construire un système d'information où humains et machines travaillent efficacement ensemble.

Source : « Spaces: A CLI Built for Humans and Agents », publié par Mistral AI le 31 mars 2026, outil conçu par Lorenzo Signoretti, Riwa Hoteit et Sam Fenwick.

Prêt à transformer ces enjeux en avantage concurrentiel ? Contactez comm.it pour en discuter.

Source : Spaces: A CLI Built for Humans and Agents | Mistral AI