Dois-je créer mon propre agent marketing IA plutôt qu'acheter un outil ?

La partie qui tient en un week-end, et celle qui n'y tient pas

La première version fonctionne, et c'est précisément ce qui trompe. Vous appelez un modèle, vous lui donnez un prompt et deux outils, et il rédige un post ou sort un rapport. Les SDK sont bons, le modèle fait le travail intéressant, et vous apprenez plus en un week-end qu'en un mois de lecture. Rien dans cette expérience n'est trompeur : ce n'est simplement pas la partie qui prend six mois.

L'autre partie n'apparaît que lorsque la chose tourne sans surveillance, sur de vrais comptes, pendant plus de quelques jours. Et c'est la même liste pour tout le monde :

• L'état Un agent qui oublie est un autre produit. Les notes, les brouillons, ce qu'il a déjà essayé : tout cela doit vivre quelque part qui survit à un redémarrage, sinon cela disparaît sans bruit.
• Les identifiants Les jetons expirent, sont révoqués et pourrissent. La panne est silencieuse : votre base contient encore une ligne indiquant "connecté" longtemps après que le fournisseur a cessé de l'honorer.
• La validation La première fois qu'un agent publiera quelque chose de faux sur un vrai compte, vous regretterez qu'une personne ne l'ait pas vu avant. Ajouter cette porte après coup, c'est réécrire le chemin d'exécution, pas cocher une case.
• Le coût La dépense par exécution est invisible tant que vous ne la mesurez pas, et un chiffre que vous n'avez pas ne peut être ni plafonné, ni facturé, ni expliqué.
• La livraison Amener le résultat jusqu'à un humain — Slack, e-mail, un tableau de bord — est un petit système à part entière, avec ses reprises et son problème de doublons.

Un test faire-ou-acheter qui tient en une séance

La bonne question n'est pas "puis-je le construire", car vous le pouvez. C'est : qui s'en occupe dans six mois, et que se passe-t-il la semaine où il casse pendant que vous livrez autre chose ? Notez honnêtement votre idée sur cinq lignes. Si la colonne de gauche domine, construisez. Si c'est la droite, vous vous engagez à maintenir une infrastructure identique dans toutes les entreprises de votre catégorie.

Cinq choses que nous avons ratées en construisant le nôtre

Nous construisons et exploitons une équipe d'agents pour les entreprises des autres, donc nous avons payé chacun de ces points en production et non dans un article. Ce sont ceux que nous n'avions pas vus venir.

1. Un conteneur qui redémarre oublie tout Nos agents tournent dans des conteneurs sans état. Tout ce qu'un agent écrivait sur le disque sans que personne ne l'ait poussé vers un stockage durable disparaissait au déploiement suivant — et l'échec est silencieux : cela se présente comme un agent qui a mystérieusement oublié une décision que vous l'avez vu prendre.
2. Une réponse 200 n'est pas un succès Une intégration nous a répondu par un HTTP 200 et une enveloppe affirmant que l'appel avait réussi, alors que le corps en dessous disait que le post avait été rejeté pour un champ manquant. Nous l'avons enregistré comme publié. On a dit au client que son post était en ligne, et il ne l'était pas. Lisez le corps, pas le code de statut.
3. Ne réessayez jamais une écriture au résultat inconnu Si l'appel lève une erreur, vous ne savez pas s'il a abouti. Réessayer, c'est exactement ainsi que la même chose est publiée deux fois. Ne réessayez que sur une réponse qui prouve que rien ne s'est produit.
4. Les contrôles de santé échouent en silence si vous ne les rendez pas bruyants Nous avions une intégration qui n'avait jamais établi la moindre connexion fonctionnelle, et notre propre alerte est restée muette, parce que la règle exigeait deux échecs dans une fenêtre qui n'en a jamais contenu deux.
5. L'étape de validation est la fonctionnalité Toute action sortante — un post, un e-mail à froid, une dépense publicitaire — attend une personne. C'est la seule chose qui rende sûr de pointer un agent vers un vrai compte, et c'est précisément ce qu'un prototype de week-end n'a jamais.

Rien de tout cela ne dit qu'il ne faut pas construire d'agent. Cela dit pour quelle moitié du travail vous vous portez volontaire. Si le flux est interne — résume ceci, rédige cela, surveille ce flux — construisez-le et amusez-vous. Dès qu'il publie, envoie des e-mails ou dépense, vous avez commencé à bâtir une infrastructure au lieu d'écrire un prompt.

Le juste milieu : construire le jugement, acheter la mécanique

La plupart des fondateurs qui s'en sortent contents ont fait ce partage. Ce qu'ils gardent, c'est ce que personne ne peut leur vendre : leur positionnement, leur offre, leur ton, le canal qui compte ce trimestre, ce qu'est un bon post pour leur audience. Ce qu'ils confient, c'est la mécanique du dessous, parce que les reprises, les validations, le stockage des identifiants, la livraison, la mesure et une piste d'audit sont identiques dans toute entreprise qui en a besoin. Construire la seconde coûte cher précisément parce qu'elle ne vous différencie pas.

Si vous achetez, posez les questions auxquelles un prototype ne peut pas répondre. Que se passe-t-il quand une publication échoue ? L'agent voit-il le résultat de sa propre action, ou ne l'apprend-il que d'un humain ? Qu'est-ce qui est journalisé, et pendant combien de temps ? Comment la dépense par exécution est-elle restituée ? Et regardez la facturation, car le coût d'un agent bouge avec ce qu'il fait, ce qui explique qu'une bonne partie de cette catégorie soit passée à la tarification à l'usage. AgentCeres — the AI Growth Officer, sur agentceres.com — est bâti sur ce partage : les agents rédigent, une personne valide tout ce qui sort, et chaque action est journalisée. Si la vraie question porte sur les personnes plutôt que sur le code, recruter un marketeur ou utiliser l'IA est plus proche.