Cette édition a été traduite de l'original anglais par une IA et n'a pas encore été relue par un traducteur humain. Les citations figurent dans leur version anglaise originale, suivies d'une traduction. Lire l'original en anglais

Le simulateur de flux de travail FestPass AI : un équipage de sept agents-nœuds — Grace à l'accueil, Marcus au profilage, Ava à la récupération des connaissances, Daniel à la conformité, Maya à l'entretien, Theo à l'inspection et Zara à l'expérience — au-dessus d'un journal d'activité et d'un presse-papiers partagé contenant l'état de l'exécution, un champ par ligne.

Partie I · Chapitre 1

Le camp devenu cabinet de conseil

L'année où les clients fictifs sont devenus de vrais clients institutionnels, et où au moins 50 campeurs ont obtenu la certification Python de freeCodeCamp.

Faites défiler pour lire

Quelque chose a changé en 2026, et ce n'était pas le code. Les campeurs apprenaient toujours Python. Deux autres choses ont changé, et toutes deux ont fait monter les enjeux.

La première, c'était pour qui ils construisaient.

Les années précédentes reposaient sur des clients fictifs : une organisation plausible, inventée pour l'exercice, qui ne pouvait pas être déçue puisqu'elle n'existait pas. 2026 les a remplacés par de vrais clients — et pas des petits. Onze clients institutionnels : des banques, une autorité portuaire, une autorité de l'eau, des administrations fiscales, un régime national d'assurance sociale. Des organisations avec de vrais clients, de vraies obligations et une vraie réputation, qui ont publié un cahier des charges, reçu une réalisation, puis l'ont jugée.

Cette substitution change tout en aval. Un client fictif ne peut pas vous dire que votre réponse le mettrait dans l'embarras. Une vraie banque le peut, et elle l'a fait.

La seconde, c'était le titre qu'ils emportaient en partant.

Les cohortes précédentes repartaient avec un certificat Python délivré par un établissement ou une plateforme en ligne crédible. Cette année, les campeurs ont passé l'examen officiel de Python de freeCodeCamp, et au moins 50 campeurs ont obtenu la certification Python — un titre reconnu dans le monde entier, vérifiable publiquement, avec une URL de certificat pour chaque campeur reçu.

La différence tient à ce que ce titre exige de vous. La certification Python de freeCodeCamp s'obtient en venant à bout d'un bloc conséquent de projets — environ trois cents heures — et les projets de certification, en particulier, demandent d'appliquer l'ensemble du programme plutôt que de le suivre pas à pas. Elle ne coûte rien au campeur. Et elle aboutit à un lien de vérification public, que l'on peut partager.

Cette combinaison est rare : un titre gratuit à obtenir, difficile à obtenir, et vérifiable par n'importe qui — un employeur, une université, un client — sans avoir à croire le camp sur parole, ni le campeur.

C'est aussi, sans bruit, la meilleure préparation que le camp pouvait leur offrir pour la suite. Un titre fondé sur des projets et un vrai cahier des charges institutionnel demandent la même chose : non pas si vous avez suivi la leçon, mais si vous savez construire la chose.

Les équipes étaient structurées comme de petites entreprises technologiques. Chacune avait un client. Chacune avait un cahier des charges publié sur un tableau que tout le monde pouvait lire. Et le programme était conçu à rebours : au lieu d'avancer à travers la syntaxe Python vers un hypothétique projet final, les facilitateurs partaient d'un produit fini et remontaient jusqu'au Python qu'il exigeait. On apprenait une boucle parce que son bot en avait besoin, pas parce que les boucles venaient ensuite.

Le virage a commencé lors d'une séance de planification, avec une question qui sonnait comme une hérésie. Can I be the devil's advocate for a moment? (« Puis-je me faire l'avocat du diable un instant ? »), a demandé Telbert Pyke, facilitateur du camp et responsable du soutien informatique. Have we thought about feeding all of this information into one of these known AI. (« Avons-nous pensé à fournir toutes ces informations à l'une de ces IA connues. »)

Cela vaut la peine de s'arrêter sur ce que cette question implique. Si un assistant généraliste sait déjà répondre à la question d'un client, que construit exactement un camp rempli d'adolescents ? La réponse à laquelle le programme est parvenu — puis qu'il a passé vingt jours à démontrer — est qu'un modèle généraliste répondra à tout, y compris par des choses qu'il a inventées, et qu'une organisation ne peut pas y apposer son nom. Ce que les équipes ont construit, ce n'était pas de l'intelligence. C'était de la responsabilité : des bots qui savaient d'où venaient leurs faits, refusaient les questions hors de leur périmètre et vous passaient à un humain quand l'enjeu l'exigeait.

Pourquoi les institutions construisent ainsi

Ce n'est pas une simplification pédagogique. C'est la raison même pour laquelle les architectures de récupération et les architectures agentiques existent dans l'industrie.

Une banque ne peut pas déployer un système qui improvise un solde. Une administration fiscale ne peut pas en déployer un qui improvise une règle d'imposition. Dès qu'une institution répond de ce que dit son logiciel, le modèle du chatbot grand public — un seul modèle, qui répond de mémoire, en une seule étape — cesse d'être déployable. Deux modèles le remplacent, et tous deux figuraient dans ce programme.

La génération augmentée par récupération fait passer le modèle du statut de source de la réponse à celui d'interface vers elle. Les faits vivent dans un corpus que l'organisation possède et gouverne — circulaires, tarifs publiés, textes de loi, barèmes — et le système puise dans ce corpus avant de parler, puis dit d'où vient la réponse. Sa valeur n'est pas de rendre le modèle plus intelligent. Elle est de le rendre auditable : on peut demander d'où vient un chiffre et obtenir un document, pas un haussement d'épaules. C'est pourquoi la première règle du camp voulait qu'un fait soit sourcé avant que le bot puisse l'énoncer, et pourquoi le Golden Record comporte une colonne dernière vérification.

L'orchestration agentique découpe le travail en nœuds aux tâches définies et aux passages de relais explicites — classer la demande, récupérer, vérifier la conformité, contrôler, escalader — au lieu de demander à un seul modèle de tout faire à la fois. Chaque étape peut être encadrée, journalisée et testée isolément, et chacune peut refuser ou passer la main. C'est la différence entre produire une réponse et dérouler un processus, et un processus est ce sur quoi une organisation peut exercer des contrôles.

Les deux modèles existent pour la même raison, et ce n'est pas la sophistication. C'est la responsabilité juridique. La récupération apporte la traçabilité ; l'orchestration apporte le contrôle. Ensemble, elles font d'un modèle de langage quelque chose sur quoi une institution réglementée peut réellement apposer son nom.

Voilà pourquoi ces formes reviennent dans chaque réalisation de ce livre. W.E.S qui refuse de communiquer un solde sans jeton valide. A.I.D.A. qui enveloppe une estimation fiscale dans un avertissement obligatoire et oriente tout cas plus difficile vers une console du personnel. ASPIRE AI qui ajoute des validateurs de schéma de sortie après que ses agents se sont emmêlés pendant les tests. PILOT qui affiche ses sources avec la date de leur dernière vérification, et confie tout ce qui touche aux douanes à un répartiteur humain.

Rien de tout cela n'est une fioriture de débutant. Ce sont les pratiques de travail du métier, auxquelles sont arrivés des adolescents qui avaient un vrai client, et donc une vraie raison d'en avoir besoin.

C'est un problème de cabinet de conseil, pas un exercice de programmation. Et c'est pourquoi, fin août, plusieurs équipes menées par des adolescents ont pu se présenter devant un jury technique régional et soutenir un contre-interrogatoire sur l'injection de prompt.