Formation technique en direct : 1 à 2 h devant des ingénieurs seniors

Les ingénieurs senior lisent votre terminal plus vite que vous parlez, et ils testent vos affirmations en posant la question que vous espériez sauter. Ce guide est le plan opérationnel pour une session en direct de 60-120 minutes sur un outil comme Claude Code, Kubernetes ou n8n : calendrier, protections de démo et ce qu’il faut dire quand quelqu’un pousse en arrière.

Structure de session

Quatre choses se produisent peu importe la longueur : gagner l’attention, définir le contexte, montrer que cela fonctionne, laisser l’audience la toucher. Gardez le contexte court — une audience senior se désaffilie par la quatrième diapositive de contexte.

Session de 60 minutes

Session de 120 minutes

Gardez l’ouverture à froid sous cinq minutes même à deux heures. Le temps supplémentaire appartient à la pratique, pas à une intro plus longue.

Ingénierie de démo

Une démo en direct est un système avec des modes de défaillance — ingénierie-le comme un.

Dépôt pré-cuit, checkpoints taguées. Construisez le dépôt à l’avance avec une balise par étape de démo. Si l’étape 3 casse mi-session, récupérez avec une commande au lieu de re-taper quinze minutes de setup :

# réinitialiser l'arborescence de travail au checkpoint step-2
git checkout step-2 -- .

Nommez les balises après l’étape, pas la date (step-2, pas oct-27), pour que le dépôt soit réutilisable.

Enregistrement de secours. Enregistrez la démo complète une fois sur le vrai matériel de présentation. Gardez-le chargé, coupé, en pause au démarrage. Si une correction en direct prendra plus de 60 secondes, basculez sur l’enregistrement et racontez par-dessus.

Configuration du terminal. Fonte de 18pt minimum, thème à contraste élevé, prompt court pour que les commandes ne s’enroulent pas. Effacez le scrollback avant de commencer pour que les erreurs antérieures ne soient pas visibles quand vous défiler vers le haut.

Modes sûrs pour n’importe quoi qui s’exécute. Décidez la garde-fou avant d’être devant des gens. --permission-mode plan sur Claude Code prévisualise les éditions sans les appliquer (la liste complète des drapeaux dans le Claude Code cheat sheet). Si l’agent doit réellement écrire des fichiers, gardez Ctrl+C plus git checkout au dernier tag comme les deux mouvements que vous savez à froid. Les Hooks qui enregistrent ou bloquent les commandes valent la peine d’être activés pour une audience qui demandera ce qui s’est passé sous le capot.

Infrastructure jetable. Pour Kubernetes, courez contre un cluster local que vous pouvez nucléer et reconstruire en moins de deux minutes — kind delete cluster --name demo puis kind create cluster --name demo (les compromis entre kind, minikube et k3d sont dans la comparaison de clusters). Pour n8n, commencez à partir d’un état docker compose connu-bon (le premier lab de flux de travail n8n) avec une deuxième instance tenant le flux de travail terminé comme sauvegarde.

Conception d’interaction

Les ingénieurs senior participent quand le format demande quelque chose de spécifique d’eux, pas « des questions ? » en silence.

• Question d’ouverture à froid. Posez quelque chose lié au travail de la salle (« qui a frappé un déploiement instable ce mois ? ») au lieu de déclarer votre bio. Appelez quelqu’un si les mains ne montent pas dans cinq secondes.
• Sondages. Un sondage tous les 30 minutes, formulé comme une prédiction (« qu’est-ce que cette commande imprimera ? »), répondu en exécutant la commande plutôt qu’une diapositive.
• Appariement. Pour le bloc pratique plus difficile, appariez les gens au lieu de les laisser en solo — l’appariement surfait les désaccords à voix haute, c’est où vous apprenez ce que la salle croit.
• Exercice « cassez-la ». Remettez la démo de travail et demandez à la salle de la casser en trois minutes. Cela produit de meilleurs cas limites que vous trouverez seul, et reframe l’échec comme attendu plutôt que gênant.

Gérer les questions pointues

Les ingénieurs senior posent des questions pour trouver l’arête de votre connaissance. Utilisez les mêmes quatre mouvements à chaque fois :

1. Reconnaître. « Bonne question » va bien si vrai ; ne le dites pas réflexivement.
2. Reformuler. Une phrase, vos mots — confirme que vous avez compris et gagne du temps pour penser.
3. Répondre ou garer. Répondre en moins d’une minute, ou l’écrire sur un parking lot visible avec le nom du demandeur.
4. Suivi par écrit. Fermez chaque élément garé dans les 24 heures, même si la réponse est « non ».

Quand vous ne savez pas : dites-le en une phrase, garez-le, avancez. Improviser une réponse insûre est le moyen le plus rapide de perdre une salle senior — elle la vérifie plus tard et se souvient de la supposition.

Quand un participant a tort : ne discutez pas du point abstraitement. Exécutez la commande ou ouvrez le doc qui le règle ; « vérifions », dit à voix haute et puis fait, règle plus qu’une correction verbale et le garde impersonnel.

Quand quelqu’un conteste la valeur de l’outil : ne le défendez pas en principe. Demandez à quoi ils le comparer et quelle barre il a besoin de franchir. Écrivez cette barre sur le parking et testez-la en direct si vous pouvez en deux minutes. Si vous ne pouvez pas, dites que l’écart est réel et avancez.

Forages de défaillance

Réheursez ces avant.

La démo casse mi-étape. Déclarez ce qui s’est cassé en une phrase, basculez sur l’enregistrement de secours ou sautez au prochain tag git, continuez à raconter. Ne vous excusez pas plus d’une fois.

Le réseau meurt. C’est pourquoi l’infrastructure est locale : un cluster kind ou une instance n8n Dockerisée continue à fonctionner sans internet. Si une démo a vraiment besoin d’une API distante, ayez une substitution hors ligne prête (réponse enregistrée, mock local) et dites que vous basculez dessus.

L’agent part du script. Un agent IA éditant des fichiers que vous n’attendiez pas a besoin d’un arrêt immédiat, pas d’une attente-et-vois. Frappez le kill switch — interrompez le processus, git checkout vers la dernière balise connue-bonne — et dites ce qui s’est passé. Encadré comme un exemple en direct de pourquoi les garde-fou importent (voir le checklist de gouvernance IA), une erreur devient du contenu au lieu d’un créneau gaspillé.

Checklist de pré-vol

Checklist post-session

Modèle réutilisable

Collez ceci et remplissez les crochets avant chaque session.

# Plan de session : [topic]

Audience : [role / seniority]
Longueur : [60 | 120] minutes
Dépôt : [url], balises step-1 .. step-N
Enregistrement de secours : [path/link]
Kill switch : [key combo or command]

## Chronologie
- 0:00 Ouverture à froid : [question ou chose cassée]
- 0:05 Contexte : [scope]
- 0:xx Démo 1 : [flux de travail]
- 0:xx Pratique : [tâche, état du dépôt de démarrage]
- 0:xx Démo 2 / cassez-la : [cas limite ou plancher ouvert]
- 0:xx Q&A
- fin Wrap : [liens, prochaines étapes]

## Parking lot
| Question | Demandé par | État | Répondu |
| --- | --- | --- | --- |

## Pré-vol
- [ ] Dépôt versionnée et taguée
- [ ] Enregistrement de secours prêt
- [ ] Infra pré-tiré et local
- [ ] Kill switch testé

Pièges

Trop de diapositives. Un deck au-dessus de dix diapositives pour une audience technique signale que vous remplissez du temps au lieu de montrer l’outil fonctionner. Coupez la diapositive, montrez le terminal.

Tout générer en direct. Taper chaque ligne de zéro est plus lent que la patience de la salle et multiplie la chance qu’une typo déraille le flux. Pré-cuisez les parties ennuyeuses ; réservez la dactylographie en direct pour la une ou deux lignes qui sont le point.

Ignorer l’expert silencieux. Chaque salle senior a quelqu’un qui ne dit rien pendant 40 minutes, puis pose la question qui révèle un écart dans votre démo. Regardez qui a arrêté de prendre des notes ou a commencé à vérifier quelque chose sur leur propre écran, et appelez-les directement pendant Q&A.

FAQ

Combien de temps une session de formation technique en direct pour les ingénieurs senior devrait-elle durer ?

60 minutes pour une démo et un bloc pratique. 120 minutes pour deux démos, une pause et un exercice d’appariement. Les audiences senior se désengagent au-delà de deux heures peu importe le contenu, alors divisez n’importe quoi de plus long en deux sessions.

Quel est le moyen le plus sûr d’exécuter une démo en direct qui pourrait échouer ?

Versionnez le dépôt avec les balises git par étape pour pouvoir sauter à n’importe quel checkpoint avec une commande, et gardez une sauvegarde pré-enregistrée de la démo complète prête à jouer. L’audience pardonne un échec ; elle ne pardonne pas cinq minutes de débogage silencieux.

Comment répondre à une question pointue que je ne peux pas répondre en direct ?

Reconnaître qu’elle a pris une réflexion, la reformuler en une phrase, puis répondre en moins de 60 secondes ou la garer sur une liste visible avec le nom du demandeur. Envoyer la vraie réponse par écrit dans les 24 heures. Deviner à voix haute coûte plus de crédibilité que de garer la question.

Et si un ingénieur senior dit que l’outil ne vaut pas la peine ?

Ne le défendez pas. Demandez à quoi ils le comparer et ce qu’il faudrait faire pour gagner un créneau. Écrivez cette barre sur le parking et testez-la en direct si vous pouvez en moins de deux minutes. Si vous ne pouvez pas, admettez l’écart et avancez.

Quel est un kill switch pour un agent de codage IA pendant une démo en direct ?

Un seul mouvement qui arrête l’agent de faire d’autres changements sans expliquer pourquoi : Ctrl+C dans le terminal, puis git checkout vers le dernier commit taguée. Décidez cela avant la session, pas pendant que l’agent est en cours d’édition.