EchoBrain ou le construire vous-même
Construire son propre harnais est parfaitement faisable et souvent le bon choix : vous obtenez un ajustement exact à vos besoins et une maîtrise totale. Ce que le calcul oublie, c'est que les huit briques d'un harnais se découvrent une par une, après incident, et qu'elles vous occuperont plus longtemps que le produit qu'elles devaient servir.
Ce que Développement interne fait mieux
Un ajustement exact à vos besoins, aucune dépendance à un éditeur, et une équipe qui comprend chaque ligne.
Ce qui nous différencie
Les dix-huit mois d'infrastructure, déjà écrits, avec les cas limites déjà rencontrés.
Construisez si l'orchestration d'agents est votre métier. Achetez si c'est votre outil.
C'est le concurrent le plus sérieux, et le seul qui gagne régulièrement. Toute équipe technique compétente peut écrire un harnais agentique. La bonne question n'est pas en sommes-nous capables — vous l'êtes — mais combien de temps y passerons-nous, et qu'est-ce que nous ne ferons pas pendant ce temps.
Ce que vous obtenez en le construisant, et que nous ne vous donnerons jamais#
- L'ajustement exact. Votre harnais fera précisément ce dont vous avez besoin, avec le vocabulaire de votre métier, sans une fonction de trop.
- Aucune dépendance à un éditeur. Ni tarif qui change, ni feuille de route qui vous oublie, ni produit arrêté.
- La compréhension totale. Une équipe qui a écrit son infrastructure la débogue à trois heures du matin.
Ces trois avantages sont réels et nous ne pouvons pas les égaler. Si l'orchestration d'agents est au cœur de ce que vous vendez, construisez : c'est votre produit, pas un outil.
Ce que le calcul initial oublie systématiquement#
L'estimation qu'on fait au départ couvre le premier tiers du travail. Voici ce qui arrive ensuite, dans l'ordre où on le découvre :
Semaine 3 — la sortie du modèle n'est pas du JSON. Vous ajoutez une validation. Puis une nouvelle tentative avec le message d'erreur. Puis un plafond de tentatives.
Mois 2 — un mail est parti deux fois. Le processus est mort entre l'envoi et l'écriture du succès. Vous découvrez qu'il faut journaliser l'intention avant l'acte, transporter une clé d'idempotence jusqu'au système distant, et réconcilier au redémarrage. Vous découvrez surtout que tous les systèmes distants ne dédupliquent pas, et qu'il faut classer chaque connecteur selon ce qu'il permet de récupérer.
Mois 3 — un client conteste une décision. Vos logs disent ce qui s'est passé, pas pourquoi. Il vous manque la version du prompt utilisée ce jour-là, le modèle exact, et le contenu de la mémoire au moment de l'appel. Vous refondez la journalisation.
Mois 5 — il faut une interface pour les validations humaines. Une file, des droits, des notifications, un historique. Vous écrivez une application.
Mois 7 — la facture des modèles est imprévisible. Vous ajoutez des budgets. Puis vous découvrez qu'il en faut trois niveaux, et qu'un repli silencieux vers un modèle moins cher est pire que le dépassement.
Mois 9 — un agent doit exécuter du code qu'il n'a pas écrit. Vous découvrez l'isolation, les quotas, et le fait qu'un composant ne doit jamais voir un secret.
Mois 12 — un deuxième client, ou une deuxième entité. Vous découvrez le multi-tenant, et vous ne le rattrapez pas après coup sans réécrire l'accès aux données.
Mois 15 — vous voulez changer de modèle. Vous n'avez aucun moyen de mesurer l'écart avant de basculer, parce que vous ne pouvez pas rejouer vos exécutions passées sur le nouveau.
Aucune de ces étapes n'est difficile. Toutes sont longues, et aucune ne se voit dans la démonstration qui a lancé le projet.
La comparaison, ligne à ligne#
| Le construire | EchoBrain | |
|---|---|---|
| Ajustement au besoin | Exact | Bon, par configuration et packages |
| Délai avant le premier processus en production | 2 à 4 semaines | Quelques jours |
| Délai avant une infrastructure de qualité production | 12 à 18 mois | Immédiat |
| Rejeu strict d'une exécution | À écrire | Fourni |
| Interface de validation humaine | À écrire | Fournie |
| Multi-tenant | À écrire, et difficile après coup | Structurel |
| Isolation d'exécution de code | À écrire | Fournie, à deux étages |
| Budgets et garde-fous | À écrire | Fournis |
| Dépendance à un éditeur | Aucune | Réelle, mais vos processus restent des fichiers de votre dépôt |
| Compréhension de l'équipe | Totale | À acquérir |
L'argument de réversibilité, retourné#
L'objection principale à l'achat est la dépendance. Elle est légitime, et récente : plusieurs offres d'orchestration d'agents lancées par de grands éditeurs ont été arrêtées, laissant leurs utilisateurs avec des configurations non exportables. Le risque n'est pas théorique.
C'est pourquoi EchoBrain est conçu pour que la dépendance soit faible :
- Vos processus sont du JSON versionné dans votre dépôt Git. Lisible sans nous.
- Vos compétences suivent un standard ouvert implémenté par d'autres outils. Réutilisables sans nous.
- Vos données sont dans votre Postgres, avec un schéma par entité. Exportables sans nous.
- Le tout tourne sur votre serveur, avec vos clés.
Si nous disparaissons, vous perdez les mises à jour. Vous ne perdez ni vos processus, ni vos données, ni votre production.
Notre recommandation honnête#
Construisez si l'orchestration d'agents est ce que vous vendez, ou si vous avez une équipe d'infrastructure dédiée qui n'a rien de plus urgent à faire pendant dix-huit mois.
Achetez si vous voulez automatiser des processus métier et que l'infrastructure n'est qu'un moyen. Le temps de vos développeurs vaut mieux que la réécriture d'un journal d'événements.
Le compromis qui marche le mieux : partez sur EchoBrain pour les processus, et gardez votre équipe sur ce qui vous différencie. Vos packages sont à vous, votre code métier reste votre code.