Ce que demande la mise en place d'EchoBrain
Mettre EchoBrain en place demande une infrastructure Docker, un accès aux systèmes que le processus doit toucher, et surtout une personne qui connaît le processus à automatiser. Le premier passage en production se compte en semaines, pas en mois : l'essentiel du travail n'est pas technique, il consiste à écrire noir sur blanc ce que vos collaborateurs décident aujourd'hui de tête.
La question posée en réunion n'est jamais « est-ce que ça marche ». C'est « qu'est-ce que ça va nous coûter en temps, et qui va devoir s'en occuper ». Cette page répond à celle-là.
Que faut-il avoir avant de commencer ?#
Trois choses, et rien d'autre.
Un serveur qui fait tourner Docker. Le vôtre, celui de votre hébergeur, une machine dans un
centre de données européen. EchoBrain se déploie avec docker compose up : une base PostgreSQL,
un moteur d'exécution, une interface. Le dimensionnement de départ tient sur quatre cœurs et huit
gigaoctets de mémoire pour un premier processus.
Un accès aux systèmes que le processus doit toucher. Une boîte mail en IMAP, une base de données, une API métier, un dossier de documents. Chaque accès est déclaré explicitement : un nœud qui n'a pas déclaré une source ne peut pas la lire, et ce n'est pas une politique de sécurité posée à côté, c'est le mécanisme d'exécution lui-même.
Une personne qui connaît le processus. C'est la ressource rare. Pas un développeur : la personne qui sait pourquoi tel message part chez tel gestionnaire, et ce qui déclenche une exception. Comptez une demi-journée d'entretien pour un processus simple, deux ou trois pour un processus qui a des cas particuliers accumulés depuis dix ans.
Faut-il des développeurs dans l'équipe ?#
Pour exploiter le produit au quotidien, non : les validations humaines se font dans une interface prévue pour des non-techniciens, et le suivi d'une exécution se lit comme un journal.
Pour écrire ou modifier un processus, il faut quelqu'un à l'aise avec un fichier de configuration versionné et la notion de schéma de données. Ce n'est pas du développement applicatif, mais ce n'est pas non plus du glisser-déposer. C'est un choix assumé : un éditeur visuel produit des processus que l'on ne peut ni relire en revue de code, ni versionner ligne à ligne, ni emporter ailleurs.
En pratique, la répartition qui fonctionne : nous écrivons le premier processus avec vous, vous le modifiez ensuite. Le fichier est dans votre dépôt, vous n'avez à demander la permission de personne.
Combien de temps avant le premier processus en production ?#
Le découpage habituel, pour un processus de complexité moyenne :
| Étape | Durée | Qui |
|---|---|---|
| Installation et raccordement aux systèmes | 1 à 2 jours | Votre équipe technique, avec nous |
| Description du processus | 0,5 à 3 jours | La personne métier |
| Écriture du graphe et des contrats | 2 à 5 jours | Nous, puis vous |
| Exécution en mode ombre sur des cas réels | 2 à 4 semaines | Personne à temps plein |
| Bascule en production, validations partout | — | Décision métier |
La phase longue est délibérée. Le mode ombre fait tourner le processus sur des cas réels sans qu'aucune action ne parte : vous comparez ce que le système aurait fait avec ce que vos collaborateurs ont fait. C'est la seule mesure honnête, et elle demande du volume, donc du temps calendaire — pas de la charge de travail.
Faut-il changer nos processus pour les automatiser ?#
Non, et c'est même le contraire de ce qu'il faut faire. Un processus réécrit pour plaire à l'outil est un processus que personne ne reconnaît, donc que personne ne valide.
En revanche, la description force à trancher des ambiguïtés que l'oral tolérait. « On relance au bout de quelques jours » devient « au bout de sept jours ouvrés, sauf pour les dossiers marqués prioritaires ». Ce travail-là n'est pas une contrainte de l'outil : c'est la partie utile.
Un signe fiable qu'un processus est un bon candidat : il existe déjà quelque part sous forme écrite — une procédure interne, un mémo, un message d'accueil pour les nouveaux arrivants.
Que se passe-t-il quand un cas particulier n'a pas été prévu ?#
Le système s'arrête et ouvre une validation humaine. Il n'improvise pas une sortie plausible, et c'est la différence de fond avec un assistant conversationnel branché sur vos données.
Une exécution en attente ne consomme aucune ressource : elle peut attendre trois semaines. Vous pouvez donc démarrer avec des points d'arrêt partout, sans arbitrer entre prudence et performance, puis en retirer au fur et à mesure de ce que vous observez. La mécanique du déterminisme et des points d'arrêt décrit ce que le moteur garantit exactement.
Sur quels systèmes EchoBrain se branche-t-il ?#
Messagerie, stockage de documents, bases de données, API HTTP, et les logiciels métier qui exposent une interface. Le catalogue est volontairement restreint et extensible par packages : nous préférons dix connecteurs dont nous garantissons le comportement à trois cents dont personne ne répond. La liste à jour est sur la page des connecteurs disponibles et de leur statut.
Pour un logiciel métier sans API, la réponse honnête est souvent non. Nous le disons avant le devis, pas après.
Peut-on récupérer des automatisations existantes ?#
Partiellement. Un enchaînement n8n ou Zapier se relit et se transpose, mais il n'a généralement pas de contrat de sortie ni de point de validation : la transposition consiste surtout à ajouter ce qui manquait. Comptez une reprise, pas une importation. C'est détaillé dans la reprise d'un enchaînement n8n ou Zapier existant.
Ce qui tourne déjà, et depuis quand#
Un bot de réunion est en production depuis le 14 août 2026 : il rejoint une visioconférence, annonce sa présence avant toute captation, transcrit, et produit un compte rendu soumis à validation. Il tourne sur EchoBrain, comme un processus client ordinaire.
Le contexte compte aussi : OpenAI a annoncé le 3 juin 2026 l'arrêt d'Agent Builder au 30 novembre 2026. Les entreprises qui avaient construit dessus n'avaient pas leurs processus chez elles. C'est précisément ce que le déploiement sur votre infrastructure évite, et le sujet de la page souveraineté des données, du modèle et de l'exécution.
Ce que la mise en place ne fait pas#
- Elle ne remplace pas votre logiciel métier. Elle s'y branche.
- Elle ne fait pas disparaître le travail de description. Elle le rend obligatoire.
- Elle ne garantit pas un gain sur un processus que personne ne sait décrire. Si l'entretien métier tourne court, le processus n'est pas mûr pour l'automatisation, et nous le disons.
Par où commencer concrètement#
Prenez le processus le plus ennuyeux et le plus répétitif que vous ayez, pas le plus stratégique. C'est celui qui donne la mesure la plus fiable, et celui dont l'échec ne coûte rien.
Les packs métier prêts à adapter sont deux points de départ documentés : boîte mail de cabinet comptable, rapprochement de factures pour l'artisanat. Sinon, une démonstration se fait sur un de vos processus.
Ce que l'on nous demande sur mise en œuvre
Combien de temps pour mettre un premier processus en production ?
Comptez une à trois semaines pour un processus qui prépare et propose, plusieurs mois avant de lui retirer la validation humaine — et c'est le bon rythme.
Faut-il des développeurs pour utiliser EchoBrain ?
Pour installer et écrire un processus, oui — un profil technique. Pour valider, corriger et suivre les exécutions au quotidien, non : c'est une interface métier.
Comment intégrer notre logiciel métier ?
Par un connecteur déclaratif s'il expose une API, par le connecteur navigateur ou un accès en lecture à sa base sinon. Comptez de quelques heures à quelques jours.
Peut-on migrer des automatisations existantes depuis n8n ou Zapier ?
Il n'y a pas d'import automatique, et c'est volontaire : une automatisation à réécrire est l'occasion de séparer ce qui relève d'une règle de ce qui relève d'un modèle.
Quel serveur faut-il pour héberger EchoBrain ?
Un serveur virtuel de quatre cœurs et huit gigaoctets suffit pour un déploiement mono-entité. Ni Kubernetes, ni service cloud managé, ni pile d'observabilité obligatoire.
Faut-il changer nos processus pour utiliser EchoBrain ?
Non, mais il faut les écrire. C'est souvent l'étape la plus utile du projet, et parfois la plus inconfortable.
Ce que nous observons sur mise en œuvre
Ce que six semaines de mode ombre révèlent vraiment
Le mode ombre sert à mesurer un taux d'accord avant d'automatiser. En pratique, il révèle surtout que le processus écrit n'est pas celui que les équipes appliquent vraiment.