Comment former une équipe à un outil qui change de comportement toutes les deux ou trois semaines ? La question s’est posée concrètement en préparant la montée en compétence d’une équipe d’intégrateurs sur l’éditeur de site expérimental du plugin Gutenberg. La réponse trouvée s’éloigne volontairement du format classique de formation.
Ce billet s’adresse à un lead technique qui doit préparer son équipe à une technologie encore instable, sans pour autant paralyser la production en cours. Il ne traite pas du recrutement de nouveaux profils — la question ici porte uniquement sur l’équipe déjà en place.
Pourquoi le format classique ne fonctionne pas
Une formation classique repose généralement sur un support figé, préparé à l’avance, dispensé une fois puis archivé. Ce modèle suppose une matière stable. Or l’éditeur de site expérimental change de comportement, parfois de vocabulaire, d’une version du plugin à l’autre. Un support préparé un lundi peut devenir partiellement obsolète le vendredi suivant, ce qui décrédibilise la formation elle-même auprès de l’équipe.
Le choix du compagnonnage
La méthode retenue s’appuie sur des binômes plutôt que sur des sessions collectives. Un intégrateur déjà familier avec le plugin Gutenberg travaille aux côtés d’un collègue moins avancé, sur un projet réel mais non critique — un site interne, par exemple, plutôt qu’un projet client sous délai serré.
- Deux personnes par binôme, jamais plus, pour garder un rythme d’échange soutenu.
- Un projet réel mais non critique, pour ancrer l’apprentissage dans du concret sans risque.
- Une rotation des binômes toutes les deux semaines, pour diffuser la connaissance plutôt que de la concentrer.
Documenter au fil de l’eau
Plutôt qu’un support de formation classique, l’équipe tient un document collaboratif vivant, mis à jour à chaque découverte notable : un comportement inattendu, une astuce de contournement, un piège identifié. Ce document remplace la documentation officielle, encore incomplète à ce stade, sans prétendre s’y substituer entièrement.
## Notes d'équipe — éditeur de site expérimental
- La zone de template part "en-tête" ne se met à jour visuellement
qu'après un rechargement complet de la page, pas en temps réel.
- Un style appliqué en ligne sur un bloc groupe écrase toujours
le style global déclaré dans theme.json.
- Toujours tester sur une installation locale avant de proposer
une manipulation à un client, même en interne.Accepter l’inconfort comme partie du processus
Une partie de la difficulté, dans cette formation, ne tient pas à la technique elle-même mais à l’inconfort psychologique qu’elle génère chez des intégrateurs habitués à une certaine maîtrise de leur outil. Reconnaître explicitement cet inconfort, plutôt que de le nier, aide l’équipe à mieux le traverser.
Une équipe qui admet ne pas tout maîtriser progresse plus vite qu’une équipe qui feint la certitude face à un outil encore mouvant.
Mesurer les progrès autrement
Impossible, à ce stade, de mesurer la montée en compétence par un examen classique portant sur des connaissances figées. La mesure retenue est plus qualitative : la capacité d’un intégrateur à diagnostiquer seul un comportement inattendu de l’éditeur de site expérimental, sans reproduire un problème déjà documenté par l’équipe.
En résumé
Former une équipe à une technologie encore instable demande d’abandonner le format classique de formation au profit du compagnonnage et de la documentation vivante. Deux semaines de binômes tournants, un document collaboratif mis à jour en continu, et une tolérance assumée à l’inconfort suffisent à construire une compétence collective solide, même sur un terrain encore mouvant.
