Par Philippe Mihelic, cofondateur et CEO de 66 Origin
Catégorie : Orchestrer humains et agents
Temps de lecture : 17 minutes
En bref
Project Casting transforme une conversation en organisation de projet. Le dialogue clarifie le problème et l’expérience, puis fait apparaître les chantiers, les compétences et les rôles IA. Ceux-ci travaillent à partir d’un corpus partagé, avec des contrôles indépendants et des passages de relais. L’IA propose et produit. L’humain arbitre et garde le final cut.
Le moment le plus pénible d’un projet, c’est avant qu’il existe vraiment
Je serais incapable de dire précisément à quel moment j’ai commencé à travailler comme ça. Il n’y a pas eu un lundi matin où je me suis réveillé avec le nom d’une méthode, six étapes bien propres et une furieuse envie de dessiner des flèches dans PowerPoint.
Au début d’un projet, il y a cette période étrange où l’on sent qu’une idée existe, mais où elle ne ressemble encore à rien. On perçoit l’objectif, on voit quelques morceaux du résultat final, mais ils flottent encore dans le désordre. C’est souvent le moment où l’on ouvre un document.
On écrit une première phrase. Elle ne va pas. On en écrit une deuxième qui ne va pas beaucoup mieux. On relit l’ensemble. On déplace un paragraphe. On revient au début. Puis, comme on a déjà passé deux heures sur une piste, on commence à la défendre un peu plus qu’elle ne le mérite.
C’est très humain. Quand une idée nous a coûté du temps, on a du mal à la jeter. Même quand elle est moyenne.
Dans mon cas, l’écrit organise trop tôt une pensée qui a encore besoin de bifurquer. Au début d’un projet, je change d’angle, je reviens en arrière et j’associe des idées qui ne s’étaient pas encore rencontrées.
À l’écrit, chaque bifurcation ressemble un peu à une correction. À l’oral, elle ressemble simplement à la suite de la conversation.
C’est ce qui a tout changé pour moi.
La voix ne me sert pas à dicter. Elle me sert à penser.
Parler me permet d’aller plus vite qu’une première version écrite. Mais la vraie différence, c’est le rebond.
Lorsque j’écris seul, je produis quelque chose, puis je dois devenir mon propre lecteur, mon propre contradicteur et mon propre éditeur. Ce sont trois métiers à la suite. Et honnêtement, ils ne sont pas toujours très bien coordonnés.
Dans une conversation vocale avec une IA qui a du répondant, les choses se passent autrement. J’expose une intuition. Elle la reformule. Cette reformulation me fait réagir. Je corrige un mot. Je précise une intention. Une nouvelle idée apparaît. L’IA la replace dans une structure que je n’avais pas encore formulée clairement.
Je peux décider en trois secondes que la piste suivie depuis dix minutes n’est finalement pas la bonne. Personne ne va me rappeler qu’on avait déjà commencé la présentation. Personne ne va demander si on ne pourrait pas conserver au moins la moitié du travail effectué.
Cette absence de coût psychologique est très importante. Elle m’évite de protéger trop longtemps une mauvaise idée simplement parce qu’elle m’a demandé des efforts.
Dans ce dialogue, je brainstorme à la fois avec l’IA et avec moi-même. J’entends mes idées au moment où je les formule et je découvre parfois ce que je pense en l’expliquant. En face, quelqu’un range un peu mieux que moi ce qui vient de sortir.
Enfin, une intelligence artificielle qui ressemble assez à un collègue pour que mon cerveau joue le jeu.
La même conversation fait apparaître le projet et l’équipe
C’est le centre de Project Casting.
La conversation ne sert pas uniquement à trouver une idée ou à produire un brief. Elle fait progressivement apparaître l’organisation capable de réaliser le projet.
Le mouvement est assez simple à décrire. Je commence par une conversation libre. L’IA en tire une première synthèse du problème. Nous précisons ensuite l’expérience recherchée, les contraintes et les questions encore ouvertes. À partir de là apparaissent les chantiers, puis leurs dépendances. Les dépendances révèlent les compétences nécessaires. Les compétences deviennent des rôles. Et chaque rôle reçoit sa fiche de casting.
Conversation libre → problème → expérience recherchée → contraintes → chantiers → dépendances → compétences → rôles → fiches de casting.
L’IA propose une première architecture. Je la corrige. Je supprime les rôles décoratifs. Je sépare les responsabilités qui ne doivent pas être mélangées. Je vérifie que deux spécialistes ne vont pas marcher sur le même chantier. Puis je valide le casting.
Dans une organisation classique, la réunion de cadrage se termine souvent au moment où le vrai travail devrait commencer. Il faut ensuite trouver les personnes, vérifier leurs disponibilités et leur raconter le projet.
Avec Project Casting, le dialogue de cadrage produit déjà la matière nécessaire pour créer les spécialistes, organiser leurs passages de relais et leur donner un socle commun. Le brainstorming ne se termine plus par une liste de personnes à appeler. Il se termine par une organisation qui peut commencer à travailler.
Qu’est-ce que Project Casting ?
Project Casting est une méthode de conception de l’organisation du travail humain–IA. Elle part d’une conversation et d’une expérience recherchée, pas d’une architecture technique préfabriquée. Elle transforme progressivement cette conversation en chantiers, en compétences, en rôles spécialisés, en documents de référence, en mécanismes de contrôle et en points de décision humaine.
Je ne prétends pas avoir inventé les agents spécialisés, les workflows séquentiels, les systèmes multi-agents, les passages de relais ou le contrôle indépendant. Ces pratiques existent déjà et sont largement documentées dans les architectures agentiques actuelles.
La contribution propre de Project Casting tient dans la continuité entre la pensée, le cadrage et le staffing. Le même dialogue qui fait apparaître le projet fait apparaître l’équipe capable de le réaliser. Les rôles sont mobilisés selon les besoins, avec une mémoire, des limites, des critères et un contrôle. L’humain reste présent partout où une décision engage le projet.
Le mot « agent » recouvre plusieurs réalités. Certains rôles sont des profils IA spécialisés qui analysent, conseillent ou produisent dans une conversation. D’autres utilisent des outils, modifient des fichiers ou exécutent plusieurs actions. Leur autonomie dépend du chantier et des droits accordés. Un rôle est défini par ce qu’il peut faire, ce qu’il doit livrer et ce qu’il n’a pas le droit de décider.
1. Commencer par l’expérience
La première erreur serait de commencer par les agents.
Quand un projet est encore flou, je ne cherche pas à savoir combien de spécialistes IA je vais créer. Je cherche à comprendre ce que le projet doit permettre et pourquoi quelqu’un aurait envie de l’utiliser.
Je décris ce que l’utilisateur doit pouvoir faire et comprendre, les informations disponibles ou manquantes, ce qui peut être automatisé, ce qui doit rester manuel et les décisions soumises à validation humaine.
À l’entrée, il y a une intuition, parfois très incomplète. Le travail consiste à la confronter, la reformuler et ouvrir les différentes possibilités sans en figer une trop tôt. À la sortie, je veux une formulation claire du problème, l’expérience recherchée, les contraintes, les questions encore ouvertes et les points qui doivent rester humains.
Je valide moi-même ce premier livrable, ou artefact de projet. La phase est terminée lorsque le problème et l’expérience peuvent être racontés simplement, sans qu’une personne extérieure comprenne autre chose que ce que j’ai en tête.
2. Transformer l’idée en chantiers et en dépendances
Une fois l’expérience suffisamment claire, le projet peut être découpé.
Il s’agit de comprendre les vrais chantiers et surtout leurs dépendances.
Qu’est-ce qui peut avancer en parallèle ? Qu’est-ce qui dépend d’un résultat précédent ? Quels fichiers ou quelles règles ne doivent jamais être modifiés simultanément ?
À l’entrée, j’ai le problème et l’expérience. Le travail consiste à cartographier les chantiers, les dépendances et les séquences. À la sortie, j’obtiens une architecture de travail avec ses zones partagées et ses risques.
Je valide le découpage avant de créer les rôles. Si deux chantiers se chevauchent trop, je les rassemble ou je les séquence. Si le projet repose sur une seule compétence et une seule responsabilité, je n’invente pas une équipe pour le plaisir de faire joli dans le schéma.
Je ne suis d’ailleurs pas le seul à me méfier des architectures trop compliquées. Les recommandations techniques les plus sérieuses conseillent elles aussi de commencer par la solution la plus simple et de n’ajouter de la complexité que lorsqu’elle devient réellement utile. [1]
Dans mes projets, trois ou quatre agents travaillent rarement en parallèle. Il peut y en avoir davantage au total, mais ils interviennent progressivement. Quand plusieurs agents codent sur la même base au même moment, le projet ressemble vite à une cuisine où chacun modifie la recette et déplace les casseroles des autres. Tout le monde travaille beaucoup. Le produit, lui, regarde.
3. Caster les rôles
Les chantiers font apparaître les compétences. Les compétences deviennent des rôles.
Une fiche de casting doit être beaucoup plus précise que « tu es un excellent développeur » ou « tu es un vétérinaire expert ». Elle définit la mission, le périmètre, les sources autorisées, les outils disponibles, le livrable attendu, les critères d’acceptation, les décisions interdites et les conditions de passation, d’arrêt ou de remplacement.
À l’entrée, j’ai la carte des chantiers et des dépendances. Le travail consiste à créer le moins de rôles possible, avec des responsabilités assez distinctes pour justifier leur existence. À la sortie, chaque rôle possède une fiche de casting exploitable.
Je valide le casting final. Je peux accepter une proposition de l’IA, supprimer un spécialiste qui ne sert à rien ou séparer deux responsabilités qu’elle avait regroupées. Celui qui définit les règles métier ne doit pas forcément être celui qui les contrôle. Celui qui produit l’interface ne doit pas décider seul si elle atteint le niveau de qualité recherché.
Le projet démarre lorsque chaque rôle connaît sa mission, ses sources et le moment où il doit rendre la main.
Un chien, quelques friandises et beaucoup trop de règles
L’un des projets sur lesquels cette méthode m’a été particulièrement utile est une application consacrée à la nutrition des chiens.
L’idée de départ tient en une phrase. Les propriétaires utilisent souvent des friandises pour éduquer leur chien. Ces friandises apportent de l’énergie. Il faut donc pouvoir les intégrer à l’équilibre de la journée et adapter le repas principal sans faire n’importe quoi.
Très vite, le sujet se déplie. Faut-il saisir les informations à la main ou photographier un paquet avec un OCR ? Que faire lorsqu’une valeur manque ? Comment calculer la quantité de croquettes à retirer, tenir compte du profil du chien et représenter son évolution ?
En quelques minutes, on n’est plus du tout en train de concevoir un compteur de friandises.
Le premier découpage fait apparaître les règles produit, la nutrition animale, l’OCR, le modèle de données, le développement mobile, l’expérience utilisateur, le design, les tests et la gouvernance des sources. Le casting comprend notamment un chef de produit, un architecte technique, un développeur, un spécialiste nutrition, un UX designer et un auditeur transversal.
Puis arrive un incident très concret.
Lors de l’activation des données personnelles de friandises dans le cloud, une modification risquait de bloquer les écrans Today, Friandises et Ajouter lorsque la table était vide. L’agent traitait l’absence de données comme une anomalie. La règle produit disait l’inverse. Un utilisateur peut commencer avec zéro friandise. Une table vide n’est pas une panne. C’est mardi matin chez quelqu’un qui vient d’installer l’application.
L’audit extérieur a comparé le comportement aux règles canoniques, isolé la contradiction et empêché la correction de déborder sur les autres écrans. Les scénarios concernés ont ensuite été rejoués pour vérifier que la correction n’introduisait aucune régression sur les autres écrans et règles de suivi.
Cet incident résume Project Casting. Le producteur avait une logique locale défendable. Le corpus portait une règle plus large. L’auditeur a diagnostiqué l’écart, préparé le rebrief et vérifié la correction sans réécrire toute l’application.
J’ai également confronté certaines règles de compensation et certains garde-fous à des vétérinaires. Ces échanges m’ont permis de vérifier leur cohérence avec une pratique de terrain, sans constituer pour autant une validation scientifique globale du produit.
4. Construire le corpus canonique
Au début, on manque d’informations. Ensuite, on en a trop, dans trop d’endroits, avec parfois plusieurs versions de la même décision.
Je ne parle donc plus d’un document unique, mais d’un corpus canonique. C’est un ensemble de documents qui font autorité sur les différentes dimensions du projet. Il peut contenir les règles métier, les décisions validées, l’architecture, la navigation, le design system, les sources externes, les tests, l’état du produit et l’historique utile des changements.
À l’entrée, il y a les livrables produits pendant le cadrage, le casting et les premiers chantiers. Le travail consiste à les organiser, à désigner leur propriétaire et à distinguer une proposition d’une règle réellement validée. À la sortie, chaque agent sait où chercher la vérité applicable à son travail.
J’applique trois règles. Chaque partie du corpus possède un propriétaire. Une décision importante est datée et validée. Et lorsqu’une contradiction apparaît, aucun document canonique n’est modifié avant mon arbitrage ou celui de l’humain responsable du projet.
La documentation n’est pas un compte rendu administratif ajouté à la fin. Elle est la mémoire opérationnelle du projet.
Le contexte disponible pour une IA n’est pas une ressource infinie. Il faut choisir ce qu’on lui donne, maintenir les informations importantes et éviter de confondre l’accumulation avec la mémoire. [2] Des recherches sur les contextes longs ont également montré que la présence d’une information dans une conversation volumineuse ne garantit pas qu’elle sera mobilisée correctement, notamment lorsqu’elle est noyée au milieu du reste. [5]
Autrement dit, l’historique de la conversation n’est pas la mémoire du projet. C’est le grenier. La documentation est la maison.
Mon petit « don’t forget »
Quand une information ne doit absolument pas disparaître, je dis à l’agent : don’t forget.
Cette instruction place l’élément dans une mémoire tampon. L’agent doit le conserver, me confirmer ce qu’il a retenu et le faire apparaître dans la prochaine passation. Mais un don’t forget n’est pas encore une règle.
Pour le devenir, l’information doit être intégrée au bon endroit dans le corpus canonique, puis validée. Une fois ce transfert effectué, elle quitte la mémoire temporaire.
Don’t forget → intégration au corpus canonique → validation → retrait de la mémoire tampon.
Ce système m’évite d’oublier une décision importante ou d’accumuler des pense-bêtes dont plus personne ne sait s’ils sont encore valables. Il existe des façons plus techniques de faire. Celle-ci a survécu à suffisamment de projets pour gagner le droit de rester.
5. Séparer ceux qui produisent de ceux qui contrôlent
Celui qui contrôle ne produit pas. Celui qui produit ne se contrôle pas seul.
Un agent qui travaille longtemps accumule du contexte, des essais et plusieurs versions d’une décision. Il peut mélanger les règles ou fabriquer une logique locale qui ne correspond plus au projet.
Le plus gênant, c’est qu’il présente cette invention avec une assurance remarquable.
Je repère la dérive lorsque le projet se met à tourner en rond. Les mêmes erreurs reviennent. Une correction en crée une autre. Les réponses deviennent plus lentes. L’agent semble connaître énormément de choses, mais plus vraiment laquelle est la bonne.
L’agent de contrôle consulte alors le corpus canonique, compare le travail aux règles et aux critères validés, diagnostique les écarts et prépare un rebrief. Il ne réécrit pas lui-même l’ensemble de la production.
Le principe n’est pas propre à Project Casting. Certaines architectures agentiques séparent déjà la production de l’évaluation. J’en ai fait une règle stricte pour préserver l’indépendance du contrôle. [1]
À l’entrée, le contrôleur reçoit le livrable, les critères d’acceptation et les références canoniques. Le travail consiste à chercher les écarts, les contradictions, les oublis et les régressions. À la sortie, il produit un diagnostic et un rebrief. Je valide les décisions qui modifient le périmètre, les règles ou la direction du projet.
Le passage à l’étape suivante est autorisé lorsque l’écart est compris et que l’on sait s’il faut recadrer l’agent existant ou repartir avec un contexte neuf.
6. Recadrer ou remplacer
Parfois, un rappel de la règle et de la bonne source suffit.
Je le remplace lorsque les règles sont oubliées plusieurs fois, que les erreurs reviennent, que les contradictions persistent ou que les corrections recréent d’autres problèmes.
Le critère final est assez pragmatique. Si le temps passé à réparer dépasse le coût d’une reprise propre, on change d’agent.
Je valide le remplacement. L’agent sortant prépare une passation avec l’état du chantier, les décisions, le travail accompli, les problèmes ouverts, les erreurs connues, les prochaines actions et les don’t forget encore en attente.
Il ne transmet pas l’historique brut. Il le compresse en un brief structuré.
Le spécialiste relit la passation. Il enlève le bruit, vérifie les décisions et complète ce qui manque. Le nouvel agent reçoit ensuite ce document, la partie pertinente du corpus canonique et sa fiche de casting.
Il ne repart pas de zéro. Il repart sans la confusion.
Les méthodes conçues pour les agents travaillant sur des projets longs utilisent elles aussi des reprises dans un contexte propre, accompagnées de documents structurés qui transportent l’état utile du travail. [3] Les outils d’orchestration proposent également des passages de relais et des garde-fous afin de mieux encadrer le changement de spécialiste. [4]
À la sortie de l’étape, le nouvel agent doit pouvoir expliquer l’état du chantier, les règles applicables, ce qu’il doit faire ensuite et ce qu’il n’a pas le droit de modifier. C’est seulement à cette condition que la production reprend.
L’humain n’attend pas le générique de fin
Le final cut humain ne signifie pas que je lance une armée d’agents, que je vais boire un café et que je reviens à la fin pour commenter la couleur du bouton. L’humain intervient tout au long de Project Casting.
Je valide le problème et l’expérience recherchée. Je valide le découpage en chantiers. Je valide le casting. J’arbitre les contradictions du corpus. J’autorise les actions sensibles. Je décide si un agent doit être recadré ou remplacé. Et je valide le résultat final.
Les IA peuvent proposer, produire, tester et diagnostiquer. Elles peuvent aussi m’expliquer avec aplomb que ma direction n’est pas terrible et qu’elles ont une bien meilleure idée. Parfois, je les écoute. Parfois, cette idée est simplement mauvaise, banale ou à côté du projet.
C’est visible dans le design. Une IA peut produire une interface fonctionnelle qui ressemble à toutes les autres. Tout est en place, tout fonctionne, et rien ne donne très envie de s’en souvenir.
Le final cut, c’est la capacité à dire que le résultat est techniquement correct mais humainement insuffisant. C’est aussi la possibilité de changer de direction alors que tout le monde, y compris les agents, a de très bonnes raisons de continuer tout droit.
Aujourd’hui, la direction créative, l’exigence et l’arbitrage ne sont pas des options que j’ai envie de décocher.
Quand Project Casting ne sert à rien
Pour un besoin simple, mon dispositif minimal tient en deux rôles. Une IA vocale m’aide à cadrer ce que je cherche. Un spécialiste exécute ensuite le travail.
Les autres rôles n’apparaissent que si la diversité des compétences, les dépendances, le volume ou le besoin de contrôle le justifient.
La bonne question est : quelles responsabilités sont réellement différentes et où ai-je besoin d’un autre regard ?
Le nombre d’agents n’est pas une mesure de maturité. Dans certains cas, en créer davantage revient simplement à organiser plus efficacement la confusion.
Project Casting ne compense pas non plus un problème mal posé, une mauvaise source ou l’absence d’expertise humaine. Une équipe d’agents parfaitement organisée peut produire très efficacement quelque chose de faux. Si personne n’est capable d’évaluer le résultat, la sophistication de l’organisation ne résout rien. Elle industrialise seulement l’erreur.
Ce que cette méthode change dans mon métier
Je comparais déjà volontiers un projet à un film. Il fallait comprendre ce que l’on voulait raconter, imaginer le résultat, puis aller chercher le bon casting. Un designer, un développeur, un ingénieur, un chef de produit ou une personne extérieure au secteur capable d’apporter un regard différent.
Avec les IA, cette logique devient plus immédiate et plus souple.
Le casting évolue avec le projet. Un spécialiste intervient, transmet son travail et quitte l’organisation. Une nouvelle compétence apparaît. Un agent est remplacé sans perdre la mémoire du chantier.
L’IA devient une extension du staffing.
Elle rend la conception de l’équipe encore plus importante. Dès lors que l’on peut créer rapidement des spécialistes, la valeur se déplace vers le choix des rôles, leur collaboration et la protection de la direction.
Le professionnel humain n’est plus seulement celui qui produit ou distribue les tâches. Il conçoit le système de travail.
Parler pour voir, caster pour faire
La voix a réduit la distance entre une intuition et sa première forme visible. Elle m’a permis de bifurquer sans protéger inutilement les mauvaises pistes. Elle a transformé le brainstorming en espace de conception du projet, puis en espace de conception de l’équipe.
Travailler avec plusieurs intelligences artificielles ne consiste plus à ouvrir plusieurs conversations et à espérer que l’ensemble produira quelque chose de cohérent.
Il faut penser les rôles, les dépendances, les documents, les critères, les contrôles et les passages de relais. Il faut savoir quand un spécialiste doit intervenir, quand un agent doit être remplacé et quelles décisions ne peuvent pas être déléguées.
Il faut surtout conserver ce que les IA peuvent nous faire oublier, précisément parce qu’elles parlent très bien : la responsabilité de savoir où l’on va.
Project Casting ne retire pas l’humain du projet. Il lui redonne le rôle de celui qui imagine le film, constitue l’équipe, protège la direction et garde le final cut.
À retenir
Project Casting conçoit l’organisation du travail dans le même mouvement que le projet. La conversation clarifie le problème, révèle les chantiers et fait apparaître progressivement les compétences et les rôles nécessaires.
La mémoire du projet ne repose pas sur l’historique des conversations. Elle repose sur un corpus canonique validé, une mémoire temporaire pour les éléments don’t forget et des passations structurées vers de nouveaux contextes.
L’autorité humaine traverse toute la méthode. L’humain valide le problème, le casting, les règles, les actions sensibles, les remplacements et le résultat final.
Sources et prolongements
[1] Anthropic — Building effective agents, 19 décembre 2024.
Sur la préférence donnée aux architectures simples, les workflows composables et la séparation entre génération et évaluation.
https://www.anthropic.com/engineering/building-effective-agents
[2] Anthropic — Effective context engineering for AI agents, 29 septembre 2025.
Sur le contexte considéré comme une ressource critique mais limitée, et sur la sélection des informations utiles.
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
[3] Anthropic — Harness design for long-running application development, 24 mars 2026.
Sur la reprise de projets longs, le renouvellement du contexte et l’utilisation d’états de référence structurés.
https://www.anthropic.com/engineering/harness-design-long-running-apps
[4] OpenAI — Agents SDK | OpenAI API, documentation officielle, consultée le 27 juillet 2026.
Sur l’orchestration, les spécialistes, les passages de relais, les garde-fous et les validations humaines.
https://developers.openai.com/api/docs/guides/agents/orchestration
[5] Nelson F. Liu et al. — Lost in the Middle: How Language Models Use Long Contexts, Transactions of the Association for Computational Linguistics, 2024.
Sur la difficulté des modèles à mobiliser de manière robuste les informations présentes dans des contextes longs.
https://aclanthology.org/2024.tacl-1.9/
PROJECT CASTING
From voice to crew
A 66 Origin method