Ce qu’un assistant d’IA doit savoir avant d’agir

Répondre n’est pas agir

Un assistant d’IA générique produit des réponses impressionnantes. Demandez-lui de rédiger une relance, il le fera bien. Mais il ne sait pas quel client est concerné, si la facture a été contestée, si un geste commercial a déjà été fait, ni qui doit signer. Sa réponse est brillante et isolée.

Agir dans une entreprise demande autre chose : savoir de quoi on parle, avoir le droit d’en parler, et connaître ses limites. Sans cela, l’IA reste un outil de rédaction. Avec cela, elle devient un agent.

Le contexte : ce que l’agent doit savoir

Le contexte utile tient en quelques éléments, toujours les mêmes, quelle que soit la tâche.

• L’objet concerné : le client, le contrat, le projet, l’équipement, le ticket.
• Son histoire : les échanges précédents, les décisions déjà prises, les exceptions accordées.
• Les règles de l’entreprise : délais de relance, seuils d’approbation, personnes responsables.
• L’état du moment : ce qui est en cours ailleurs, qui est disponible, ce qui a déjà été tenté.

Ce contexte n’existe que si l’information est reliée. Un agent branché sur des outils qui ne se parlent pas reconstruit une version partielle de la réalité, comme les équipes avant lui. C’est pour cela qu’un système commun est le préalable, et que le Business OS précède l’agent.

Autorisé : ce que l’agent a le droit de voir

Voir tout n’est pas une qualité. Un agent qui accède à toutes les données de l’entreprise est un risque, pas un atout. Le bon principe est celui des droits par rôle : l’agent voit ce que son périmètre autorise, comme n’importe quel membre de l’équipe.

Cela vaut aussi pour ce qui est transmis aux modèles d’IA. Le nécessaire, pas l’intégralité. Un conseiller financier n’a pas besoin du grand livre complet pour expliquer un écart. Un agent de relance n’a pas besoin des dossiers du personnel.

La confiance : savoir quand s’abstenir

Un agent utile connaît son niveau de confiance. Quand le signal est clair et la règle établie, il agit ou prépare l’action. Quand le signal est ambigu, il demande. Quand il n’a pas assez de données, il le dit, au lieu de remplir le vide.

Ce comportement se vérifie plus qu’il ne se promet. Un agent qui cite ses sources, indique sa confiance et laisse une trace peut être contrôlé. Un agent qui affirme sans montrer ne le peut pas.

Une bonne réponse dit ce qu’elle sait, ce qu’elle suppose et ce qu’elle ignore.

Les limites : ce qu’il ne décide jamais seul

Les limites d’un agent sont des décisions de gestion, pas des réglages techniques. Elles se résument à trois garde-fous que nous avons détaillés dans Automatiser sans retirer la décision humaine : un seuil, une validation, une trace.

Concrètement, un agent peut préparer une relance, créer un ticket, prévenir la bonne équipe ou signaler un écart. Il ne déclenche pas un paiement, ne modifie pas un contrat et n’envoie pas une communication sensible sans approbation. Vous gardez la main, et la trace le prouve.

Murphy, l’agent qui veille

Dans Neoo, cet agent s’appelle Murphy. Il n’attend pas vos questions. Il surveille vos ventes, vos factures et vos tickets, détecte les retards, prépare les relances, signale les anomalies et déclenche les actions autorisées, selon les règles de votre entreprise.

Le scénario type se déroule en quelques étapes : un signal apparaît, Murphy le replace dans son contexte, propose une action cadrée, obtient la validation quand elle est requise, puis exécute et trace. Le même mécanisme s’applique aux incidents techniques, décrits dans Voir un incident avant qu’il ne devienne une urgence.

Ce que Murphy sait, il le sait parce que l’entreprise est reliée. Ce qu’il fait, il le fait parce que vous l’avez autorisé. C’est la différence entre un assistant qui parle et un agent qui travaille pour vous. Vous pouvez le voir à l’œuvre sur la page Murphy.