Du chatbot à l'équipage

Le premier jour, on avait démonté un chatbot au tableau blanc et nommé ses pièces : interface, cerveau, mémoire, personnalité, chemins de décision, outils. Six composants, pour que personne dans la salle ne puisse employer le mot chatbot sans savoir ce qu'il y a dedans.

The bot is the GPS, (« Le bot, c'est le GPS ») leur a dit T. Valerie Onu ce premier matin. The human is the driver. (« L'humain, c'est le conducteur. »)

Tout ce qui a suivi s'est construit sur ce cadre. Un bot dictionnaire qui associait une question à une réponse enregistrée, et la découverte rapide du peu qu'il pouvait porter. Des garde-fous, pour qu'il refuse plutôt que d'improviser. Le Golden Record, pour que chaque fait arrive accompagné d'une source et d'une date. La récupération, pour que la réponse sorte d'un document appartenant au client plutôt que du souvenir qu'a le modèle d'internet.

Au début de la quatrième semaine, les campeurs avaient un bon bot. Mais il n'avait qu'une forme, et cette forme ne variait jamais : une question arrive, le système va chercher quelque chose, une réponse repart.

Un tour. Une décision. Une responsabilité.

Le vrai travail n'arrive pas sous cette forme.

Avant l'IA, le flux de travail

L'étape suivante n'avait rien de technique.

On a demandé aux campeurs d'observer des processus métier ordinaires et fastidieux — le genre de file d'attente que tout le monde a connue un jour — et de les décomposer en flux de travail. Non pas « demander un prêt » comme un événement unique, mais comme une séquence : qui intervient, dans quel ordre, ce dont chaque personne a besoin en main avant de pouvoir agir, et ce qui se passe quand ce dont elle a besoin n'est pas là.

Cette dernière question s'est révélée être tout le sujet.

Ils se sont exercés sur des simulations avant de s'approcher du problème d'un client, et ces simulations étaient volontairement ludiques — délivrer un pass de festival, suivre une demande de bout en bout, faire avancer la séquence pas à pas et observer ce qui s'accumule sur le presse-papiers partagé au fil du parcours. L'intérêt d'une simulation, c'est qu'on peut la relancer, et la casser exprès. Personne n'a ce loisir avec une banque.

C'est en la cassant exprès que l'on apprenait vraiment. Un flux de travail qui se déroule toujours sans accroc n'enseigne rien, parce que tout processus réel passe l'essentiel de sa vie dans les exceptions. Chaque simulation était donc livrée avec ses défaillances intégrées : le pass de festival sans justificatif d'âge. Le paiement qui échoue. La pièce d'identité trop floue pour être lue.

C'est seulement alors que l'automatisation est arrivée — et elle est arrivée sous forme de question plutôt que d'outil. Lesquelles de ces étapes un système pourrait-il prendre en charge ? Lesquelles un humain doit-il garder ? Et que doit-il se passer au moment précis où une étape ne peut pas aboutir ?

C'est avec Tariq que cette question a trouvé son exemple concret.

Tariq veut un prêt

C'est toute la prémisse, et elle est volontairement ordinaire. Il entre dans une banque — ou ouvre une fenêtre de discussion, ce qui, en 2026, revient au même — et demande de l'argent pour développer une entreprise. Ce qui se passe ensuite n'est pas une question avec une réponse. C'est une séquence, et chacune de ses étapes appartient à quelqu'un de différent.

Quelqu'un doit l'accueillir et comprendre ce dont il a réellement besoin. Quelqu'un doit établir qui il est et quel type de client il est. Quelqu'un doit consulter ce que disent les règles de la banque en matière de prêt. Quelqu'un doit confronter ces règles à ses documents. S'il manque quelque chose, quelqu'un doit revenir vers lui pour le lui demander — ce qui signifie que la séquence doit pouvoir faire demi-tour. Quelqu'un doit inspecter le résultat avant qu'il ne parte. Et quelqu'un doit le rendre à Tariq dans une langue dont il puisse se servir.

Demandez à un chatbot unique de faire tout cela et il essaiera. Il inventera aussi, quelque part en chemin, et sans bruit, une règle de prêt.

Pourquoi nous l'avons enseigné comme un équipage

C'est le moment où le camp cesse d'enseigner les chatbots d'IA générative pour enseigner l'ingénierie de l'IA agentique.

Un équipage n'est pas un chatbot avec davantage de prompts. C'est le même problème découpé en tâches nommées, chacune avec ses propres entrées, ses propres contraintes et son propre droit de refuser. Tariq's Digital Crew (l'équipage numérique de Tariq) a donné un visage à ces tâches : Grace accueille, Marcus établit le profil, Ava récupère ce que disent les règles, Daniel vérifie la conformité, Maya mène l'entretien quand il manque quelque chose, Theo inspecte, Zara rend la décision.

Sept agents, un presse-papiers partagé et — c'est ce qui compte le plus — une arête qui revient en arrière. Quand Daniel constate qu'un document manque, le travail n'échoue pas et ne continue pas non plus. Il revient à Maya, qui demande à Tariq la pièce manquante, et c'est seulement ensuite qu'il avance.

D'abord raconté comme une histoire

Rien de tout cela ne passe sous la forme d'un schéma d'architecture un mardi matin.

On l'a donc enseigné comme une histoire. Le camp a créé des bandes dessinées pour les agents, donnant à chacun un caractère avant d'en faire une fonction, et a produit une vidéo retraçant le parcours de Tariq, de la demande à la réponse. Les campeurs ont rencontré Grace, Daniel et Maya comme des personnes ayant un métier avant de les rencontrer comme des nœuds dans un graphe.

Cet ordre était tout l'enjeu. Un adolescent de quinze ans qui a suivi la demande de Tariq entre sept paires de mains comprend déjà les passages de relais, l'état et le routage conditionnel — il ne sait simplement pas encore que ce sont les mots pour le dire. Quand le code arrive, ce n'est pas une idée nouvelle. C'est son idée, écrite en Python.

Puis vient la partie difficile

Le récit vous mène jusqu'à l'idée. Il ne vous mène pas jusqu'à un système de production, et le camp n'a pas prétendu le contraire.

Le framework vers lequel les campeurs ont été conduits est LangGraph, et il vaut la peine d'être précis sur ce que cela signifie, car il est facile de supposer qu'un programme d'été choisit l'outil le plus doux disponible. Il a fait l'inverse.

LangGraph est un framework de bas niveau. En génie logiciel, bas niveau signifie un contrôle fin et un code plus explicite — on ne vous fournit pas d'abstractions qui réfléchissent à votre place. Là où un framework de haut niveau permet à un développeur de décrire le rôle d'un agent en langage courant et de faire confiance au modèle pour trouver les étapes, LangGraph exige d'écrire trois choses à la main :

Les nœuds — les blocs de code ou les appels au modèle précis qui exécutent une action.

Les arêtes — la logique conditionnelle et les chemins de décision qui relient ces actions, y compris ceux qui reviennent en arrière.

L'état — un schéma central qui consigne exactement ce que l'équipage sait à chaque instant.

Parce qu'il ne cache rien de tout cela derrière des abstractions commodes, il donne un contrôle absolu sur les boucles, l'autocorrection et l'intervention humaine dans la boucle. Ce contrôle est la raison même pour laquelle les entreprises le choisissent. Quand un agent qui hallucine peut coûter de l'argent à une banque, on veut une machine à états aux limites strictes, pas un pilote automatique susceptible de s'égarer.

Pourquoi le bas niveau, précisément

Le camp aurait pu opter pour un framework de haut niveau. Cela aurait été plus rapide, plus doux, et aurait produit dès l'après-midi quelque chose de présentable. Il a choisi de ne pas le faire, et la raison était la sécurité.

Dans un framework de haut niveau, c'est le modèle qui décide de la suite. C'est l'argument de vente — décrivez un rôle, et le système trouve les étapes. C'est aussi, très exactement, la surface d'attaque.

L'injection de prompt consiste à faire entrer dans le contexte d'un modèle un texte que le modèle traite comme une instruction. Si le modèle ne fait qu'écrire une réponse, une injection réussie produit une mauvaise réponse. Si le modèle choisit aussi l'itinéraire, une injection réussie choisit l'itinéraire : sauter le contrôle de conformité, atteindre un outil qu'il n'était jamais censé toucher, renvoyer un chiffre que personne n'a vérifié. Une seule instruction manipulée, et le rayon d'impact, c'est tout le flux de travail.

Écrivez le graphe explicitement et cette catégorie d'attaque n'a nulle part où aller. Une injection peut encore corrompre ce qu'un nœud dit. Elle ne peut pas inventer une arête qui n'existe pas. Elle ne peut pas contourner Daniel, parce que Daniel n'est pas une suggestion — c'est un nœud par lequel le trafic passe. Elle ne peut pas appeler un outil que le graphe n'a jamais câblé. L'autorité du modèle s'arrête à la frontière du nœud dans lequel il s'exécute.

Voilà ce que signifie le durcissement ici. Non pas un filtre ajouté après coup, mais une architecture dans laquelle les chemins dangereux n'ont jamais été construits.

C'est aussi ce qui a donné tout son intérêt à l'atelier du neuvième jour. Les campeurs ont passé une séance à tenter de jailbreaker leurs propres bots, et cet exercice n'enseigne quelque chose que s'il existe une structure contre laquelle tester. Cassez un pilote automatique et vous avez prouvé qu'on peut convaincre un modèle de faire des choses, ce que tout le monde savait déjà. Cassez un graphe codé et vous avez découvert exactement quel nœud a fui et précisément ce qu'il avait le droit d'atteindre — une conclusion assez étroite pour être corrigée.

Et c'est pourquoi CUB-VA a pu énoncer son invariant aussi platement : il ne demandera, ne conservera ni ne révélera jamais d'identifiants bancaires confidentiels — ni numéros de compte, ni mots de passe, ni soldes. Un agent qui décide de sa propre étape suivante ne peut pas honnêtement promettre cela. Un agent qui ne parcourt que des chemins écrits par quelqu'un le peut.

Ce que cela exige vraiment d'un apprenant

LangGraph est une mise en œuvre directe de la théorie des graphes et des machines à états appliquées à l'IA générative. Bien l'utiliser fait appel aux graphes orientés et cycliques, à la persistance des données et à la programmation asynchrone — des fondamentaux de l'informatique, pas des astuces de chatbot. C'est un classique des cours universitaires avancés et des ateliers d'IA de niveau production, et on le considère généralement comme trop avancé pour quelqu'un qui construit son premier prototype.

Il a été enseigné à des adolescents caribéens pendant la quatrième semaine.

Où en est réellement le domaine

Il vaut la peine d'être clair sur le caractère récent de tout cela. La récupération et l'orchestration d'agents ne sont pas des pratiques établies adossées à une décennie de manuels. Elles sont le problème vivant de l'IA appliquée — en train d'être résolu en ce moment même, en production, par des équipes nettement mieux dotées qu'un programme d'été.

La raison en est que le modèle n'a jamais été la partie difficile. N'importe quelle organisation peut appeler une interface de programmation d'applications (API). Ce qui sépare une démonstration de quelque chose sur quoi une banque apposera son nom, c'est tout ce qui est agencé autour du modèle : d'où viennent les faits, ce que le système a le droit de dire, ce qui se passe quand une étape échoue, et vers qui il escalade quand il ne devrait pas répondre du tout. C'est cela, l'orchestration, et c'est là que se situe aujourd'hui la véritable difficulté.

Voilà l'affirmation qui mérite d'être faite à propos de ce programme, et elle est étroite. On n'a pas remis aux campeurs la technologie de la décennie passée reconditionnée pour l'école. On les a emmenés dans la partie du domaine qui fait encore débat — et on leur a demandé d'y livrer quelque chose.

class State(TypedDict):        # what the crew knows, exactly
    applicant: str
    documents: list[str]
    missing_items: list[str]
    compliance_status: str

def daniel(state: State) -> State:          # the NODE
    missing = required_docs() - set(state["documents"])
    return {
        **state,
        "missing_items": sorted(missing),
        "compliance_status": "pass" if not missing else "hold",
    }

def route(state: State) -> str:             # the EDGE
    return "maya" if state["compliance_status"] == "hold" else "theo"

graph.add_node("daniel", daniel)
graph.add_conditional_edges("daniel", route)   # loops back on a fail

L'atelier que les campeurs ont suivi est public, et le reste. Il construit un agent de récupération ligne par ligne — ce que vous tapez d'un côté, ce que LangGraph fournit de l'autre, et la façon dont chaque étape correspond à l'organisation d'agents que vous avez dessinée avant d'écrire la moindre ligne de code.

Ce que les campeurs en ont retiré

Alors retirons le cadre du chatbot et regardons ce que les vingt jours ont réellement transmis.

La théorie des graphes, appliquée. Nœuds, arêtes, flux orientés et cycliques — non pas comme une abstraction, mais comme ce qui décide si la demande de Tariq revient en arrière ou poursuit sa route.

La conception de l'état. Un schéma de ce qu'un système sait à chaque instant, et la discipline de raisonner sur ce qui se passe quand une partie en manque.

Le flux de contrôle dans l'incertitude. Quand réessayer, quand interrompre, quand s'arrêter et passer la main à un humain. La plupart des logiciels partent du principe qu'ils réussiront ; les agents doivent être écrits par quelqu'un qui part du principe qu'ils échoueront.

La récupération dans un corpus gouverné. Ancrer une réponse dans une source qui appartient à quelqu'un, et la citer.

Les tests adverses. Le neuvième jour, les campeurs ont attaqué leurs propres systèmes, en vertu du principe qu'il faut penser comme un hacker et construire comme un défenseur.

La validation des sorties. Validateurs de schéma, conditions de refus, et l'habitude de ne pas se fier à la sortie d'un modèle simplement parce qu'elle se lit bien.

Le déploiement. FastAPI vers GitHub vers Render, et une commande de démarrage qui doit être exactement juste.

Et Python, à un niveau évalué de manière externe.

Les sept premières sont celles qu'un responsable du recrutement reconnaîtrait comme des compétences de niveau senior. La dernière est celle qui tient sur un certificat. Ce qui ne figure sur aucune liste, c'est le jugement qui sous-tend tout cela — savoir quand un système doit refuser — et c'est la partie qu'on ne peut pas aller chercher ailleurs.

Le transfert

Une rigueur de ce genre ne compte que si elle survit au contact d'un vrai client, et c'est là que les vingt jours peuvent être audités plutôt que décrits.

W.E.S achemine une urgence avant de demander un nom — une arête conditionnelle, empruntée parce qu'une cour inondée ne peut pas attendre derrière une vérification d'identité. A.I.D.A. escalade vers une console du personnel plutôt que d'improviser une décision fiscale — un nœud d'intervention humaine, placé exactement là où une erreur coûte le plus. ASPIRE AI a ajouté des validateurs de schéma de sortie après que ses agents se sont emmêlés lors de tests à plusieurs tours, c'est-à-dire un problème d'état diagnostiqué et réparé par ceux-là mêmes qui l'avaient causé. PILOT confie tout ce qui touche aux douanes à un répartiteur portuaire — une condition d'arrêt, écrite délibérément plutôt qu'espérée.

Ce ne sont pas des fonctionnalités que quiconque a pensé à demander. C'est à cela que ressemble un graphe quand la personne qui le dessine a compris que la partie la plus difficile d'un agent, c'est de savoir quand il doit s'arrêter.

Sur scène, en regardant leur propre système passer la main correctement sous pression, une équipe l'a dit plus simplement que tout cela : That is what agentic means in practice! (« Voilà ce que signifie l'agentique en pratique ! »)