Une organisation d'entreprise pilotée par des agents IA

Le contexte

Je dirige seul un cabinet de conseil. La difficulté n’est pas technique, elle est arithmétique : une journée contient une quantité finie d’heures, et quatre activités se disputent les mêmes. La production client passe toujours en premier, c’est normal. Mais la veille sur les vulnérabilités, la présence publique et le suivi commercial ne disparaissent pas pour autant, ils s’accumulent.

J’ai donc construit un banc d’essai personnel, que je fais tourner sur ma propre activité. Ce n’est pas un système qu’une PME monterait chez elle : ce qui se transfère, c’est la connaissance des modes de défaillance de ces systèmes, pas le système lui-même.

Le problème

La question n’a jamais été « est-ce que l’IA peut écrire un texte ». Elle le peut, tout le monde le sait, et cela ne construit aucune organisation.

La vraie question est celle-ci : qu’est-ce qui empêche un système automatique de faire, un dimanche à trois heures du matin, quelque chose que je devrai désavouer publiquement le lundi ? Je ne peux pas déléguer une action engageante à un système probabiliste sans savoir précisément où sont les limites, qui les fixe, et ce qui se passe quand elles sont atteintes.

Les contraintes

• Coût maîtrisé. Un système qui appelle des modèles de langage en continu peut coûter très cher très vite, sans prévenir.
• Plateforme gratuite ou presque. Je l’ai prise pour son prix. En échange, le socle d’exécution impose des limites strictes : nombre d’appels sortants par invocation, durée maximale d’une tâche, quotas quotidiens.
• Aucune surface publique laissée sans contrôle. Le système s’exprime sur des réseaux sociaux et par e-mail, donc au nom de mon cabinet.
• Traçabilité. Toute décision automatique doit être relisible après coup.

Mon intervention

J’ai conçu et je maintiens l’ensemble : architecture, développement, exploitation.

Le système s’organise autour de quatre composants aux rôles séparés. Un service d’exécution permanent porte les tâches planifiées et les réactions aux événements extérieurs. Un poste de pilotage me donne la vue d’ensemble et la main. Des cycles d’agents spécialisés traitent chacun un domaine de l’activité. Enfin, une base documentaire versionnée sert de source de vérité unique : c’est là que vit ce que le système sait de l’entreprise, et rien ne s’exécute à partir d’une connaissance qui n’y figure pas.

L’architecture

Le choix structurant est la séparation entre la mémoire et l’exécution. La connaissance de l’entreprise vit dans des fichiers versionnés, lisibles par un humain, avec un historique complet. Les composants d’exécution la consultent, mais aucun ne la détient. Modifier une règle de fonctionnement, c’est modifier un document et le valider, pas éditer du code en production.

Le second choix est l’étagement des traitements longs. Une génération de contenu enchaîne plusieurs appels lents à des modèles, ce qui dépasse largement le temps alloué à une invocation. Plutôt que de contourner la limite, je découpe : chaque tâche longue avance d’une étape à chaque cycle, en conservant son état entre deux passages. Le système est donc reprenable par construction. Si une étape échoue, elle reprend là où elle en était au lieu de tout recommencer.

Le troisième choix est le point de passage unique vers les modèles. Tous les appels transitent par un seul composant, qui porte le plafond de dépense, la journalisation et le comportement en cas d’échec. Il n’y a pas de second chemin : ajouter une fonctionnalité, c’est forcément passer par ce point de contrôle.

Les choix techniques

L’exécution repose sur une plateforme sans serveur, facturée à l’usage et bornée par des quotas. Je l’ai prise pour son coût, très faible, et non pour ses propriétés : un serveur classique n’aurait imposé ni limite de durée ni limite d’appels. Ses limites m’ont obligé à découper le travail en étapes courtes et reprenables, et ce découpage subi s’est révélé meilleur : le système tombe proprement au lieu de tomber brutalement.

Le pilotage vit sur ma machine et n’est pas exposé sur Internet : je préfère perdre le confort d’y accéder depuis n’importe où plutôt que d’exposer un poste de commande.

Dans le service d’exécution, les échanges avec les modèles ne passent par aucune bibliothèque intermédiaire : d’abord par compatibilité avec le moteur d’exécution, ensuite parce que des appels réseau bruts me laissent la maîtrise du comportement en cas d’erreur, de délai dépassé ou de réponse tronquée. Ce sont exactement les cas qui font tomber les intégrations d’IA en production, et ceux que les couches d’abstraction masquent le mieux. Le poste de pilotage, lui, utilise la bibliothèque officielle.

La sécurité

C’est le cœur du sujet.

Rien d’engageant ne part sans accord humain. Les actions qui touchent l’extérieur produisent une demande d’approbation que je valide ou rejette.

Les protections sont dans le code, pas dans les consignes. J’ai appris cette règle à mes dépens : une consigne demandant à un modèle de ne pas divulguer son raisonnement fonctionne la plupart du temps, et « la plupart du temps » n’est pas une garantie. Un jour, le raisonnement interne est passé en clair sur une surface publique. La correction n’a pas consisté à mieux formuler la consigne : elle consiste à faire passer toute sortie publique par une fonction de nettoyage qui, elle, ne peut pas changer d’avis. Le prompt demande, le code garantit. C’est devenu une règle d’architecture, appliquée à toute nouvelle surface.

Le budget est un interrupteur, pas une alerte. Un plafond de dépense quotidien est vérifié avant chaque appel. Au-delà, les appels s’arrêtent.

Les chemins d’écriture sensibles sont figés. Les composants qui modifient la base de connaissance ne peuvent écrire qu’à des emplacements inscrits en dur, et le contenu est validé structurellement avant d’être accepté. Un modèle qui déciderait d’écrire ailleurs en est empêché par le code.

La conformité est traitée comme une contrainte technique. Les visuels produits par IA portent la mention exigée par le règlement européen sur l’intelligence artificielle, incrustée par le code au moment du rendu et non demandée au modèle.

Le résultat

Le système fonctionne au quotidien depuis 2025. Il produit et soumet des contenus à validation, répond aux sollicitations publiques, surveille les vulnérabilités connues activement exploitées à partir des sources officielles, alimente la page d’actualités de ce site, et me signale ce qui mérite mon attention. Le reste du temps, il se tait.

Ce que j’en retire de plus utile pour mes clients, ce ne sont pas les contenus produits. C’est la connaissance précise de l’endroit où ces systèmes cassent : les délais dépassés qui ne remontent aucune erreur, les quotas atteints en silence, les tâches tuées au milieu d’un traitement, les garde-fous qui tiennent en démonstration et cèdent en production.

Ce que ce projet démontre

Je ne me contente pas d’utiliser l’IA, je conçois l’organisation autour, avec la répartition des rôles qui va avec : la machine exécute, l’humain décide, et la frontière entre les deux est inscrite dans le code plutôt que dans une intention.

Pour une PME, cela se traduit directement. La question n’est jamais « quel outil d’IA acheter », mais « quelles tâches peuvent être déléguées, sous quel contrôle, avec quel plafond de dépense, et qui répond quand le système se trompe ». J’ai répondu à ces quatre questions sur mon propre système avant de les poser à un client.