Comment un designer pilote un modèle opérationnel IA

Le produit, ce n’est pas le site. C’est la boucle.

Ce site est la partie visible d’une boucle. Apprendre comment le marché s’exprime. Utiliser ce langage pour construire le site. Utiliser le site pour attirer des gens. Observer ce qu’ils font. Apprendre, et ajuster.

Aujourd’hui, la boucle tourne grâce à la recherche et aux entrevues avec des utilisateurs. L’analytique est en place, mais le trafic est encore trop faible pour m’apprendre quoi que ce soit. La boucle se refermera vraiment quand la diffusion commencera.

L’échelle a commencé avec un tableur

Pendant des années, ma carrière vivait dans des présentations, des CV et ma mémoire. Chaque version était un peu différente. On ne pouvait rien construire dessus.

L’échelle a commencé le jour où toute ma carrière a tenu dans un seul classeur : 18 mandats, 30 résultats documentés, 13 cas. Chaque résultat est écrit deux fois, une fois dans les mots des acheteurs et une fois dans ceux des recruteurs. Chaque chiffre vit dans une seule cellule : il ne peut pas se désaligner d’une page à l’autre ni d’une langue à l’autre. Le site est généré à partir de ce classeur. Je ne modifie jamais une page d’étude de cas à la main. Le classeur est ensuite devenu la graine de tout ce qui a suivi. J’ai toujours su que la structure façonne la surface ; j’ai des études de cas à ce sujet. En travaillant seul, à l’échelle d’une personne, je l’ai vu directement sur mon propre site.

Les ingénieurs reconnaîtront le geste. La méthode des éléments finis prend une structure trop complexe pour être résolue d’un bloc, la découpe en petits éléments, définit chaque élément et ses interfaces, puis les assemble et résout le système. Le classeur fait la même chose avec une carrière : les mandats, les résultats et les cas sont les éléments ; leurs identifiants sont les interfaces ; le générateur assemble ; la compilation résout. Sans cette clarté de tableur, concevoir un flux de travail est presque impossible. On ne peut pas automatiser ce qu’on ne sait pas nommer.

Décider qui fait quoi

La plus vieille question du travail humain-automatisation n’est pas « une machine peut-elle le faire ? ». C’est « qui devrait le faire ? ». Paul Fitts a dressé en 1951 la liste de ce que les humains font mieux et de ce que les machines font mieux. Sheridan et Verplank ont décrit les niveaux d’automatisation en 1978. La pratique d’intégration humain-système de la NASA appelle cela l’allocation des fonctions. J’appelle cette façon de travailler la collaboration calibrée : chaque fonction va à qui la fait le mieux, et la confiance suit les résultats.

Ma version est une petite matrice à trois colonnes :

Fonction	Qui	Pourquoi
Sens, positionnement, goût, décisions finales	Moi	Le jugement est l’actif que le site existe pour vendre
Recherche, ébauches, mise en œuvre, investigation	IA	Rapide, infatigable et vérifiable
Invariants : parité bilingue, anonymat des clients, règles de liens	Script	Un fait appliqué par un script ne peut pas se désaligner

La dernière ligne compte le plus. La règle : si un script peut appliquer un fait, qu’il l’applique ; n’écrire en prose que ce qui ne peut pas l’être. Huit semaines de preuves la soutiennent. Le système bilingue, vérifié par un script, ne s’est pas désaligné une seule fois. Les descriptions en prose de la pile technique se sont désalignées onze fois.

Le but, c’est une confiance calibrée : une confiance envers l’IA qui correspond à son historique, tâche par tâche. La recherche en facteurs humains appelle cela la dépendance appropriée (Lee et See, 2004). Trop de confiance livre des erreurs. Trop peu gaspille l’outil.

Les diagrammes comme couche d’alignement

Les mots laissent place à deux lectures. Un diagramme en laisse moins. J’utilise des diagrammes pour aligner l’IA sur moi, et pour aligner une session d’IA sur la suivante, car chaque nouvelle session commence sans mémoire de la précédente. Les recommandations actuelles vont dans le même sens : des références riches, comme des maquettes HTML, valent souvent mieux que des descriptions écrites (Claude, 2026). The Shape of Work, ma notation, pousse cette idée plus loin : une grammaire visuelle du travail lui-même.

La gestion de l’information est le vrai métier

Les problèmes difficiles n’étaient pas visuels. Ils portaient sur l’endroit où vit la vérité.

• La mémoire se désaligne de la réalité. Les notes décrivent le code ; le code change ; les notes, non. Quand ils divergent, le code l’emporte, et on corrige les notes.
• Statique contre dynamique. Les règles sont intemporelles et appliquées. Les préférences sont actuelles et appelées à changer. Elles vivent dans des sections séparées, pour qu’un goût ne se fige jamais en architecture.
• De la source au contexte. L’information circule dans un seul sens : classeur → copie des données → générateur → pages. Pour l’IA : règlement → journal des décisions → documentation des sous-systèmes → code. Chaque couche se lit dans cet ordre, et la lecture s’arrête quand la tâche a ce qu’il lui faut.
• Trois dépôts, trois rôles. Le dépôt de code contient le comment et le pourquoi. L’espace projet contient la réflexion en cours. La mémoire ne contient que l’endroit où nous en sommes.

J’aime cette partie. C’est un problème de design sans écran.

Des maquettes au dépôt

Jusqu’en janvier 2026, je concevais dans Figma et je construisais sur Wix. En février, je suis passé au code. Aujourd’hui, je livre directement dans le dépôt, je construis mes propres outils graphiques et je pilote le projet depuis un tableau de bord que j’ai construit.

Outil	Ce qu’il fait	Statut
The Shape of Design	Génère les diagrammes de mes cours de design	En service
The Shape of Work	Outil de notation et de tracé du travail comme système	En cours
Copy Monitor	Planifie les changements de texte avant qu’ils n’atteignent le code	En service
Tableau de bord du projet	Un tableur qui pilote le projet d’un coup d’œil	En service

Ce que cela veut dire pour une équipe

La plupart des équipes ont adopté des outils d’IA sans changer l’organisation du travail. Les outils ne sont pas la partie difficile. Nommer les éléments, allouer les fonctions et vérifier les invariants : voilà la partie difficile. C’est le travail que j’offre désormais à mes clients.

Références

• Fitts, P. M. (dir.) (1951). Human engineering for an effective air-navigation and traffic-control system. National Research Council.
• Sheridan, T. B., et Verplank, W. L. (1978). Human and computer control of undersea teleoperators. MIT Man-Machine Systems Laboratory.
• Lee, J. D., et See, K. A. (2004). Trust in automation: Designing for appropriate reliance. Human Factors, 46(1), 50–80.