Commençons par lever une ambiguïté de vocabulaire, parce qu'elle est à l'origine de beaucoup de malentendus sur ce marché. Chez nous, l'orchestration désigne la machine qui exécute. L'orchestrateur désigne la personne qualifiée qui pilote cette machine chez vous. Les deux mots se ressemblent, ils ne désignent pas la même chose, et le second est un métier.

Les briques, dans l'ordre où une demande les traverse

  • Une porte d'entrée unique. Formulaire, e-mail, messagerie, appel d'un autre logiciel : tout arrive par un point de passage qui authentifie, valide le format et enregistre.
  • Une base de données qui fait autorité. Chaque demande y devient une ligne, avec son état. Les agents ne travaillent jamais sur une copie qui traîne ailleurs.
  • Une file d'attente. Tout ce qui est long, coûteux ou faillible passe par elle, avec nouvel essai et abandon motivé.
  • Des agents spécialisés. Un agent, une mission, un périmètre d'outils. Pas un agent unique qui saurait tout faire.
  • Une couche de règles déterministes. Placée entre les agents et le monde extérieur, elle refuse les actions interdites avant qu'elles ne partent.
  • Un journal. Chaque action porte son auteur, son motif, son coût, son résultat.

Où sont stockées les données

Dans une base relationnelle hébergée dans l'Union européenne, avec des règles d'accès appliquées ligne par ligne : un utilisateur ne peut lire que ce que son rôle autorise, et cette vérification a lieu côté serveur, jamais côté navigateur. Les documents et pièces jointes vivent dans un stockage privé accessible uniquement par liens signés et temporaires.

Les appels aux modèles ne transportent que ce dont la tâche a besoin. Ce point mérite d'être posé à tout prestataire : envoyer l'intégralité d'une base à un modèle pour répondre à une question simple est à la fois coûteux et inutilement risqué.

Comment les agents communiquent

Pas en discutant entre eux en langage naturel, ce qui est spectaculaire en démonstration et ingérable en production. Ils communiquent par l'état de la demande dans la base : un agent lit un état, produit un résultat structuré, écrit le nouvel état. Le suivant prend le relais.

L'avantage est décisif au moment du diagnostic : on peut ouvrir n'importe quelle demande et lire exactement qui a fait quoi, dans quel ordre, avec quel résultat. Une conversation entre agents ne laisse pas cette trace.

Un système que l'on ne peut pas relire après coup n'est pas un système. C'est une boîte noire avec des factures.

Les droits

Trois niveaux, tous nécessaires. Le niveau utilisateur, avec des rôles et des habilitations vérifiées à chaque requête. Le niveau agent, où chaque agent reçoit le strict minimum d'outils et d'accès nécessaires à sa mission. Le niveau action, où les opérations à effet externe passent par la couche de règles, quelle que soit leur origine.

Ce dernier niveau est le plus important, et le plus souvent absent : la même vérification doit s'appliquer à l'action lancée par un agent et à celle lancée par un humain depuis l'interface. Sinon la sécurité dépend du chemin emprunté, ce qui revient à ne pas en avoir.

Les erreurs

Nouvel essai avec temporisation sur les défaillances passagères, abandon motivé et alerte au-delà, repli documenté quand un modèle est indisponible, seuil de confiance qui renvoie vers un humain, et annulation réelle des actions réversibles. Nous détaillons ce dispositif, et la leçon qui l'a fait naître, dans l'article sur les erreurs.

Comment vérifier

Demandez une démonstration en trois écrans, pas une présentation : le journal d'une demande réelle du début à la fin, l'écran où un humain valide une action, et le comportement du système quand on provoque une erreur. Un prestataire qui a construit cela peut le montrer immédiatement. Notre page Orchestrateur IA explique le reste : qui pilote, avec quel engagement, et sur quels accès l'IA s'exécute.