L’IA au centre ou l’IA comme liant : deux façons de construire un harnais

Pour une majorité de tâches, le modèle ne fait plus la différence

Ce qu’une entreprise attend de l’IA porte, pour une majorité de tâches, sur des opérations précises et répétées : relier deux informations, résumer un échange, corriger un texte, trier le signal du bruit dans une boîte de réception. Presque tous les modèles récents les font bien ; choisir l’un plutôt que l’autre n’y change presque rien.

Le vrai choix est ailleurs. On peut viser large : un gain de temps réel et fiable pour la plupart des équipes, sur des tâches quotidiennes. Ou viser haut : confier à des agents plus autonomes le travail des experts les plus pointus, en acceptant que la sécurité passe de quasi certaine à incertaine. Le premier choix rapporte davantage à l’échelle d’une entreprise, sans rien céder sur la sécurité. C’est celui que PipeDuck sert.

Encore faut-il une architecture qui rende ces tâches fiables partout. C’est là que les harnais, tout ce qui entoure le modèle, se séparent en deux familles.

Deux façons de construire un harnais

Dans la première famille, l’IA est au centre. On lui donne un objectif et des accès ; elle explore, décide de ses appels, lit ce qui revient et recommence jusqu’à atteindre son but. Les agents de code fonctionnent ainsi. C’est la bonne architecture quand la tâche est ouverte et qu’un spécialiste relit le résultat, à condition qu’il fasse tourner l’agent sur une machine aux accès très restreints. Dans beaucoup d’entreprises, les développeurs n’ont d’ailleurs plus d’accès en écriture aux bases de données de production, parfois même plus en lecture, pour éviter les fuites ; l’agent, qui travaille avec leurs droits, hérite de ces limites.

La seconde famille, celle de PipeDuck, inverse le rapport. Le processus est dessiné, et chaque étape prend la forme qui lui convient : un script, peu coûteux et au résultat déterministe, donc reproductible et fiable ; une étape IA pour les cas complexes que le script gère mal, ou pour les décisions à faible enjeu ; une personne pour les grandes décisions, et pour en porter la responsabilité. À la conception, l’IA aide à transposer vos idées en étapes et à les relier : ce travail ne se paie qu’une fois, et une personne le relit. À l’exécution, elle ne travaille que dans les étapes qui lui reviennent, avec le modèle et les outils choisis pour chacune. Le code appelle l’IA plus que l’IA n’appelle le code.

Le rapport Excel quotidien, dans les deux architectures

Chaque matin, un export de commandes arrive dans un fichier Excel, et quelqu’un doit en tirer le chiffre d’affaires par région, les meilleurs produits et les anomalies à traiter.

Dans la première architecture, une IA reçoit le fichier chaque jour, le lit en entier et calcule. Nous avons fait le test sur un export de 1 000 commandes contenant huit anomalies placées au hasard, avec Claude Opus 5 réglé sur son effort de raisonnement maximal, sans outil de calcul. Le rapport attendu compte 23 résultats : le chiffre d’affaires total et celui de chacune des six régions, les cinq meilleurs produits avec leur montant, le nombre de commandes pour chacun des quatre statuts, le panier moyen, et la liste des anomalies, qui doit retrouver les huit sans en inventer. Les 23 sont justes. Le travail a demandé 16 minutes et demie et près de 116 000 tokens, soit environ 3,24 $ au tarif public de l’API¹. Le modèle a eu juste parce qu’il a refait chaque calcul par deux chemins indépendants, ce qui l’a aussi rendu cher.

Dans la seconde architecture, l’IA sert une fois. L’assistant de construction de PipeDuck aide à écrire les règles du rapport, un script les applique, et une personne relit ce script avant qu’il ne tourne. Ensuite, chaque matin, le même rapport sort en 6,5 millisecondes, sans token, et sans qu’aucun modèle ne lise les données des clients.

Sur 250 jours ouvrés, la première architecture coûte environ 810 $ pour un seul rapport, et chaque matin garde une chance d’erreur. Notre test a eu juste une fois ; il ne dit rien des 249 autres jours. Or une IA qui réussit 99 % de ses exécutions ne passe une année entière sans erreur qu’environ une fois sur douze. Des règles vérifiées rendent le même résultat chaque jour.

Face à Claude Code, à n8n et à Zapier

Claude Code, que nous utilisons nous-mêmes et avec lequel nous avons mené ce test, est un excellent harnais, pour le code : un outil agentique qui lit une base de code, modifie des fichiers et exécute des commandes, dans des limites fixées par des permissions et par un bac à sable du système³. L’IA y est au centre, ce qui convient à une tâche ouverte relue par un développeur. Un processus d’entreprise qui revient chaque jour, conduit par des personnes qui ne programment pas, appelle l’architecture inverse.

n8n et Zapier sont les concurrents les plus proches, et ils font beaucoup de choses bien : des étapes IA dont on choisit le modèle, des validations humaines, le partage d’identifiants sans en montrer le secret^{4, 5}. Nos différences sont ailleurs. Dans PipeDuck, chaque version d’un script est relue avant de pouvoir s’exécuter : résumé des changements et notes de sécurité produits par IA, puis approbation d’une personne ; chez n8n, cette relecture passe par une pull request chez le fournisseur Git, hors de l’outil, sur les offres Business et Enterprise⁴. Et PipeDuck est hébergé en France ou s’installe chez vous, avec votre propre modèle si vous le souhaitez, quand Zapier n’existe qu’en ligne⁵. Surtout, les routes diffèrent : n8n et Zapier sont nés pour connecter des applications et y ont ajouté l’IA ; nous sommes partis des règles d’une entreprise et du code relu, et nous avons placé l’IA entre les deux.