La question arrive presque toujours pareil : « on achète un outil d’agents ou on se le construit ? ». Et elle est presque toujours mal posée, parce qu’on la pose dans l’abstrait —comme si « acheter » et « construire » étaient deux religions et qu’il fallait choisir un camp—. Ils ne le sont pas. Ce sont deux outils pour deux types de problème différents, et la seule réponse utile dépend d’une chose : si le processus que tu vas automatiser est ton avantage compétitif ou un péage que tu paies comme tout le monde.
Je l’écris du côté de celui qui le maintient ensuite en production, pas de celui qui signe le deck. Et de là, le motif est têtu : la plupart des entreprises achètent là où elles devraient construire et construisent là où elles devraient acheter. Elles montent un chatbot de support sur mesure —six mois de développement pour ce que fait n’importe quel produit du marché— et en même temps fourrent leur processus le plus particulier, celui que personne d’autre n’a, dans un outil rigide qui ne le comprend pas. L’erreur n’est pas d’acheter ni de construire : c’est de le faire à l’envers.
Ce que gagne acheter (et où ça te coule)
Acheter un produit d’agents —une plateforme, un SaaS avec IA, un assistant vertical— te donne de la vitesse. Quelqu’un a déjà résolu les 80 % génériques : l’interface, l’intégration avec le commun, la gestion d’erreurs, les mises à jour quand le modèle en dessous change. Si ton problème est standard —classer des tickets, répondre aux questions fréquentes, planifier—, acheter est presque toujours le bon choix : tu paies pour ne pas réinventer une roue qui roule bien.
Où ça te coule : dans les derniers 20 %, qui sont d’habitude justement là où vit ta différence. L’outil acheté suppose un flux « normal », et ton opération a une exception qui, pour toi, n’en est pas une : c’est le métier. Quand tu essaies de plier le produit pour qu’il la fasse, tu commences à payer en intégrations fragiles, en « ça ne se configure pas » et en lock-in : le jour où tu veux changer, ton processus vit dans leur boîte. Acheter est bon marché au début et cher quand ton cas cesse de ressembler à celui de la brochure.
Ce que gagne construire (et où ça te ruine)
Construire —monter l’agent sur les API des modèles, avec ta logique et tes données— te donne du contrôle et un ajustement exact. L’agent fait ton processus, pas une approximation. Si ce processus est ton avantage —la façon particulière dont tu qualifies un lead, priorises une commande ou revois un contrat—, construire est ce qui le protège : tu ne le mets dans la boîte de personne, tu le transformes en logiciel à toi. C’est le cas où le sur-mesure gagne sans discussion.
Où ça te ruine : quand tu construis ce qui existe déjà. Faire sur mesure un chatbot de FAQ ou un classifieur générique, c’est payer trois fois —le développement, la maintenance et le coût d’opportunité de ne pas l’avoir acheté tout fait—. Et attention, car construire ne finit pas le jour où ça marche : un agent en production doit être surveillé, versionné et réparé quand le modèle en dessous change de comportement. Si tu vas construire le générique, tu signes une hypothèque de maintenance pour posséder quelque chose de pire que ce qui se vend sur le marché.
| Axe | Acheter | Construire |
|---|---|---|
| Time-to-value | Jours ou semaines | Semaines ou mois |
| Ajustement à ton processus | Celui de la brochure, exceptions forcées | Exact : il fait le tien |
| Coût initial | Bas (abonnement) | Élevé (développement) |
| Coût à long terme | Monte avec le lock-in et les rustines | Maintenance continue, mais il est à toi |
| Où ça brille | Problèmes standard et communs | Là où le processus est ton avantage |
La règle : le processus est-il ton avantage ou ton péage ?
Toute la décision tient en une question : ce processus est-il quelque chose sur quoi tu es en concurrence, ou quelque chose que tu paies comme tout le monde ? Si c’est un péage —nécessaire mais indifférencié, pareil pour toi et pour ton concurrent—, achète le meilleur du marché et n’y touche pas. Si c’est ton avantage —la raison pour laquelle un client te choisit—, ne le sous-traite pas à une boîte rigide : construis-le, parce que tu transformes ton savoir-faire en actif. Avant de décider, quatre questions honnêtes :
- Quelqu’un vend-il déjà ça et le fait-il bien ? Si oui et que ton cas ressemble à celui de la brochure, achète. Ne construis pas un agent juste pour te vanter qu’il est à toi.
- La partie difficile est-elle ma différence ou de la plomberie ? Si le difficile est l’intégration standard, un produit le résout. Si le difficile est ta logique particulière, c’est là que construire paie.
- Combien me coûte le lock-in si ça grossit ? Un processus core dans la boîte d’un fournisseur est une dépendance stratégique, pas une ligne de dépense. Compte ce coût avant, pas quand tu veux sortir.
- Puis-je le maintenir ? Construire sans équipe (interne ou externe) pour surveiller l’agent en production, c’est acheter de la dette. Si tu ne pourras pas le maintenir, achète-le même s’il s’ajuste moins bien.
Il y a une troisième voie presque toujours la bonne, et que la fausse dichotomie « acheter ou construire » cache : acheter la base et construire par-dessus uniquement la couche qui te différencie. Tu utilises des modèles et des outils du marché pour les 80 % génériques et tu mets ton ingénierie seulement dans le morceau qui est à toi. C’est ce qu’on fait quand on monte des agents IA pour une entreprise : on ne réinvente ni le modèle ni le connecteur standard ; on construit la logique de ton processus par-dessus des pièces déjà résolues. Ni tout tout fait ni tout sur mesure : chaque chose où il faut.
L’erreur de le faire à l’envers
L’échec coûteux n’est pas de mal choisir dans le doute ; c’est de choisir par réflexe. L’entreprise technique construit par instinct —« nous, on fait ça nous-mêmes »— et se retrouve avec trois agents génériques à moitié maintenus qu’un produit à 40 € par mois ferait mieux. L’entreprise non technique achète par instinct —« qu’un outil s’en occupe »— et fourre son processus le plus précieux, celui qui la distingue, dans un SaaS qui l’aplatit jusqu’à le rendre identique à celui de tous. Les deux ont brûlé de l’argent et du temps à optimiser la mauvaise case.
La façon de ne pas y tomber est de séparer avant de décider : fais l’inventaire des processus que tu vas toucher et marque chacun « péage » ou « avantage ». Les péages, à acheter ; les avantages, à construire (ou à acheter-la-base-et-construire-dessus). Quand le partage n’est pas clair, commence par acheter et observe où le produit t’oblige à te plier : ce point de friction est, presque toujours, le signe qu’il y a là quelque chose de tien qui mérite son propre code. Si tu veux la carte du quand automatiser un processus avec des agents et quand non, on la développe dans le guide sur automatiser des processus avec des agents ; et si tu préfères que quelqu’un monte la partie sur mesure sur ton opération sans que ça devienne un pilote zombie, c’est ce que font les employés IA.