À quoi ressemble concrètement le dilemme « développer ou acheter » dans l'ingénierie agentique ?

La plupart des débats « faire soi-même ou acheter » partent du principe que tu fais un choix unique, au début, et que tu dois t'y tenir.

L'ingénierie agentique ne fonctionne pas comme ça. Cette décision se pose à chaque couche de la stack, et les équipes qui réussissent ne sont pas celles qui ont choisi « développer » ou « acheter » comme philosophie. Ce sont celles qui savent distinguer les différentes couches.

Patrick Dawkins, ingénieur logiciel principal chez Upsun, a participé à la création de l’agent interne de révision par IA d’Upsun avant même qu’Upsun Dispatch™ n’existe en tant que produit, puis a contribué au développement d’Upsun Dispatch lui-même. 

Au fil du temps, il a dû prendre la même décision à trois niveaux différents de la stack, et il est arrivé à une réponse différente à chaque fois. C’est plus utile qu’un framework, car ça montre où le raisonnement change réellement.

La prolifération d’outils que personne n’a choisie

Avant qu’il n’y ait de plateforme, il y avait des ordinateurs portables. Les ingénieurs choisissaient leurs propres outils, exécutaient leurs propres agents en local, et tout le monde pensait que ça allait parce que ça avait toujours fonctionné comme ça. Dawkins a vu les failles apparaître.

« Quand tu fermes ton ordinateur portable, ça s’arrête de tourner », a-t-il dit. « Tu ne peux pas prendre l’avion là où il n’y a pas de Wi-Fi, ni simplement arrêter de bosser, aller dormir pour la nuit et laisser tes agents tourner. » À Londres, il l’a dit plus clairement : monter dans le métro mettait fin à tout ce qu’un agent était en train de faire.

C’est un petit désagrément pour une seule personne. À l’échelle d’une organisation d’ingénierie, c’est une faille de gouvernance. Personne en dehors de cet ordinateur portable n’a la moindre visibilité sur ce que l’agent a réellement fait. La décision d’« achat » ici n’en était pas vraiment une. Laisser chaque ingénieur choisir son propre outil est devenu, par défaut, toute la stratégie IA de l’organisation, sans que personne ne l’ait approuvée. 

La solution, ce n’était pas un meilleur outil individuel. C’était de mettre en place un système suffisamment centralisé pour que le travail ne disparaisse pas dès la fermeture de l’écran.

La solution à moindre coût, et ce qu’elle coûte par la suite

Il existe un moyen plus rapide de faire en sorte qu’un agent fasse un vrai travail, et Dawkins ne prétend pas le contraire. « Tu peux utiliser des outils comme OpenClaude, ou Claude avec des autorisations “dangerously-skip”, en tant qu’individu », a-t-il déclaré. Pas de barrières d’approbation, pas de contraintes, un accès complet à l’outil, tu le laisses tourner jusqu’à ce que l’objectif soit atteint. « Mais en tant qu’organisation, ça ne nous aide pas. »

Le fossé entre ces deux phrases résume tout le débat. Ignorer les autorisations, ça marche bien jusqu’à ce qu’un auditeur de conformité ou un client soumis à une réglementation commence à poser des questions auxquelles tu ne peux pas répondre. 

Dawkins appelle cette alternative « l’ingénierie de contention » : donner à un agent suffisamment d’outils pour qu’il soit vraiment utile tout en limitant précisément ce qu’il a le droit de toucher, en le faisant tourner dans un bac à sable qui est supprimé dès que la tâche est terminée. 

C’est plus long à mettre en place. C’est aussi la solution qui tient la route quand quelqu’un te demande comment tu sais que c’est sûr.

À quoi ressemble la décision d’un vrai fournisseur ?

Quand Dawkins a dû choisir un fournisseur de sandbox pour Dispatch, il n’a pas fait de supposition. Son équipe a construit des prototypes jetables sur plusieurs options pour voir comment chacune se comportait réellement.

Le résultat a été presque décevant. Les options se sont avérées si proches en termes de capacités que le choix n’avait pratiquement aucune importance sur le seul plan technique. L’équipe en a donc choisi une et a délibérément maintenu la couche d’infrastructure découplée de celle-ci, considérant cette décision comme réversible plutôt que définitive. 

C’est là que réside le véritable savoir-faire lorsqu’il s’agit de choisir entre « construire » et « acheter » au niveau de la couche d’infrastructure : reconnaître quand le choix n’a pratiquement aucune importance, et construire en prévoyant la possibilité de changer d’avis plutôt que de parier sur le fait d’avoir fait le bon choix dès le départ.

Achète le produit standard, développe ton jugement

La même logique se retrouve un niveau plus haut, au niveau du modèle lui-même. Upsun Dispatch a commencé par permettre aux clients d’apporter leur propre clé Anthropic plutôt que de créer dès le départ une couche d’accès au modèle propriétaire. Achète le produit standard. Ne refais pas ce qu’un laboratoire de pointe fait déjà bien.

Ce que Dawkins développe à la place, c’est la partie qu’on ne peut pas acheter toute faite : un cadre d’évaluation permettant de comparer scientifiquement les modèles, pour que les choix en matière de coût, de qualité et d’effort de raisonnement ne relèvent plus de la conjecture. 

« Souvent, tu en as pour ton argent », dit-il, « mais pas tout le temps. » Savoir dans quels cas et pour quelles tâches, c’est ça le vrai produit.

Le principe qui sous-tend ces trois décisions

Achète les éléments qui sont véritablement des produits de base : un environnement d’exécution de type « sandbox », un modèle de pointe, la puissance de calcul brute sous-jacente. Développe les éléments pour lesquels ton propre jugement est en réalité le produit : les contraintes, l’évaluation, le raisonnement que tu devrais défendre face à quelqu’un qui ne l’a pas conçu. 

Upsun Dispatch existe parce que Dawkins s’est retrouvé trois fois face à cette bifurcation et a toujours abouti à la même réponse.

• Tu es nouveau ici ? Lis l’introduction à Upsun Dispatch.
• Tu veux contribuer à son développement ? Postule pour rejoindre la promotion des partenaires fondateurs en conception.