L'IA qui a dit Non.

Publié le 19 janvier 2026 par Raff Paquin

Imaginez la scène : je réfléchis à une nouvelle fonctionnalité pour mon application de gestion de budget depuis vendredi soir.

Enfin, lundi matin. Je suis excité par l'idée et prêt à la développer. Je travaille une bonne vingtaine de minutes pour peaufiner les specs, et le ticket est prêt : R-648 — Ajouter le support de comptes d'investissement via Plaid.

Dans Linear, j'assigne le ticket à mon agent Obi.

Obi rejoint la session, démarre une instance cloud pour récupérer la dernière version du code, et assigne le ticket à mon équipe de gestion de produit.

J'ai hâte. Une nouvelle fonctionnalité sera bientôt disponible pour mes utilisateurs ; j'ai juste le temps de me resservir un thé.

Je regarde Linear pour vérifier le statut : travail terminé.

Cool.

Je regarde le résultat. Pas de code. Pas de PR. Rien.

À la place, ce message :

Fonctionnalité déprioririsée et annulée. La valeur client proposée dans R-648 n'est pas alignée avec les problèmes clés identifiés lors de la recherche client.

Mon IA vient de me dire Non.

Ce système, spécifiquement conçu pour toujours donner ce que l'utilisateur demande, a refusé de travailler sur ma fonctionnalité.

Que s'est-il passé ?

Ce n'était pas un bug. C'était voulu. Et ça pourrait bien être l'avenir de la façon dont nous construisons des produits. La plupart des systèmes d'IA d'aujourd'hui sont conçus pour être serviables. Presque pathologiquement. Demandez à ChatGPT ou Claude de construire quelque chose, et ils le construiront, même s'ils doivent inventer des données pour le faire. Je suis sûr que vous connaissez le terme : hallucination.

Et si au lieu d'une seule IA désireuse de plaire, vous aviez une équipe produit ? Une équipe capable de remettre en question vos idées, d'exiger des preuves, et parfois de vous dire que vous avez tort ?

C'est ce qui vient de rejeter ma fonctionnalité.

Comment des agents concurrents prennent de meilleures décisions

Si j'avais simplement demandé à un agent de codage de travailler sur R-648, il aurait rapidement tout construit, sans poser de questions. Mais j'ai configuré mon compte Obi différemment. Avant de coder toute nouvelle fonctionnalité, la plateforme exécute une validation par trois agents :

Agent 1 : L'optimiste. Argumente en faveur de la fonctionnalité demandée. Il doit présenter une analyse de rentabilité ancrée dans les données pour soutenir ses arguments.
Agent 2 : Le pessimiste. Argumente contre la fonctionnalité. Même exigence : il doit ancrer son raisonnement dans la recherche client et l'analyse rationnelle.
Agent 3 : Le Juge. Écoute les deux agents débattre, pèse les preuves, et prend une décision finale sur la poursuite ou non du projet.

Les agents auraient pu avoir accès aux entretiens clients, aux analyses d'utilisation, et à ma feuille de route produit. L'agent pessimiste a découvert que le problème clé que est la gestion de trésorerie, rien en lien avec les investissements à long terme. L'optimiste n'a pas pu construire un argument convaincant contre ce fait. Le juge à décidé d'annuler ma demande.

J'étais déçu pendant environ trente secondes. Puis j'ai réalisé : c'est exactement ce qu'une bonne équipe produit devrait faire.

C'est un exemple relativement simple de flux de travail multi-agents, trois agents dans une seule boucle. Mais d'autres systèmes sont bien plus complexes. Prenez le projet Trading Agents, où douze agents spécialisés collaborent pour développer des stratégies de trading, chacun apportant différentes perspectives analytiques et contraintes.

Les opportunités ici sont infinies. Mais aujourd'hui, implémenter, tester, itérer et faire évoluer des systèmes multi-agents reste assez complexe, et accessible uniquement aux personnes techniques.

C'est le problème que je résous avec Obi.

À propos d'Obi

Obi est l'un de mes projets de recherche. Il est actuellement disponible en version privée partagée avec quelques amis de confiance. Mon objectif pour l'instant est d'explorer ce qui est possible lorsqu'on donne aux utilisateurs la capacité d'orchestrer des équipes d'agents spécialisés.

À la base, Obi est une infrastructure d'orchestration pour agents cloud. Au lieu de gérer des assistants IA individuels, vous créez des flux de travail multi-niveaux (pensez organisations, pas seulement employés). Vous pourriez avoir une équipe de recherche, une équipe marketing, et une équipe QA, toutes avec des objectifs et des contraintes différents.

Les flux de travail sont déclenchés par des appels API ou des outils externes intégrés à la plateforme. Par exemple :

Déclencheur Gmail : Quand je reçois un email d'un client, le router vers mon équipe de support pour triage et ébauche de réponse
Déclencheur Google Calendar : Quand une réunion commence, me briefer sur les participants et le contexte récent
Déclencheur Plaid : Quand une transaction suspecte arrive sur ma carte de crédit, enquêter et m'alerter
Déclencheur de prix d'action : Quand une entreprise que je suis atteint un seuil, analyser s'il est temps d'agir

Ce sont des exemples simples. Le vrai pouvoir vient quand vous enchaînez ces déclencheurs ensemble dans des flux de travail sophistiqués où les agents collaborent, débattent, et prennent des décisions.

Pour l'instant, je suis simplement enthousiaste de voir où cette recherche mène. Nous sommes encore aux débuts de la compréhension de comment orchestrer efficacement plusieurs agents IA.

Mais si mon IA peut me sauver de moi-même de temps en temps, nous sommes peut-être sur quelque chose d'important!