La conversation revient presque mot pour mot à chaque rendez-vous. Le responsable informatique est convaincu : son équipe doit monter en compétences sur le cloud, la migration est engagée, la facture dérape, personne ne sait recréer un environnement autrement qu’en cliquant. Puis vient la phrase qui bloque tout : « je ne peux pas sortir trois personnes pendant une semaine ».
Elle est parfaitement fondée. Dans un service de trois à six personnes, retirer deux ingénieurs cinq jours d’affilée, c’est allonger le délai de traitement des incidents, décaler les projets et reporter l’astreinte sur ceux qui restent. Le calcul n’est pas idéologique, il est arithmétique. La réponse n’est donc pas de convaincre le responsable que ce n’est pas grave : c’est de concevoir la formation pour qu’elle tienne dans la contrainte.
Le facteur limitant n’est pas le budget, c’est l’astreinte
Le devis d’un parcours cloud dépend du programme, de sa durée et du niveau d’adaptation au groupe. Un autre coût, celui qui n’apparaît dans aucun devis, c’est l’indisponibilité de l’équipe.
Il faut donc le chiffrer honnêtement, avec le responsable, avant de parler de programme. Combien d’incidents de niveau 2 ou 3 par semaine ? Quelle est la charge d’astreinte de la personne qui restera seule ? Quelles échéances projet tombent dans le trimestre ? Cette conversation dure une heure et détermine tout le reste : le découpage, la taille du groupe, les dates, et parfois la décision de commencer par deux personnes plutôt que quatre.
C’est aussi à ce moment qu’on écarte la fausse bonne idée du distanciel « en fond de tâche ». Une personne qui suit une formation cloud depuis son poste, en gardant la messagerie et le téléphone d’astreinte ouverts, ne suit pas une formation : elle assiste à une visioconférence en travaillant. Sur des sujets qui demandent de tenir un raisonnement d’architecture pendant deux heures, le résultat est nul et le budget est perdu.
Découper : trois fois deux jours valent mieux qu’une fois cinq
Le format qui fonctionne le mieux dans une équipe sous contrainte n’est pas la semaine complète, c’est la série de sprints de deux jours espacés de deux à trois semaines. Trois raisons, dans cet ordre d’importance.
D’abord, l’équipe reste couvrable : deux jours d’absence se compensent, cinq non. Ensuite, l’intervalle sert de laboratoire réel — entre deux sprints, les participants appliquent sur leur propre environnement ce qu’ils viennent de construire, et reviennent avec des questions issues de leur système d’information, pas du support. Enfin, l’oubli. Une compétence d’ingénierie apprise puis inutilisée pendant six semaines disparaît ; réactivée à trois reprises à quinze jours d’intervalle, elle s’installe.
Le prix à payer est réel, il faut l’annoncer : cette formule demande un travail intersession d’environ une demi-journée par participant, et une discipline de planification que tout le monde n’a pas.
| Sprint | Contenu en salle | Travail intersession |
|---|---|---|
| 1 — Architecture | Zone d’atterrissage, découpage des abonnements, identités et gouvernance, chiffrage du coût mensuel de la cible | Cartographier l’existant réel et le confronter à la cible dessinée en salle |
| 2 — Code | Terraform : état distant, modules, environnements multiples, revue de plan intégrée à la chaîne d’intégration continue | Reprendre en code un composant existant déjà créé à la main |
| 3 — Exploitation | Supervision, alertes utiles, sauvegarde et reprise, suivi budgétaire et arbitrages FinOps | Exécuter un test de restauration documenté et daté |
Ce qu’il faut préparer avant le premier jour
Une formation cloud échoue rarement pendant la formation. Elle échoue à J-10, quand on découvre que les participants n’ont pas les droits nécessaires, que la direction des systèmes d’information n’a pas validé la création d’abonnements de test, ou que deux personnes sur cinq n’ont jamais écrit une ligne en ligne de commande.
Trois préparatifs suffisent à supprimer la quasi-totalité de ces incidents.
Le test de positionnement, d’abord. Vingt minutes par participant, envoyées quinze jours avant. Il ne sert pas à noter, il sert à écarter le scénario le plus destructeur : deux profils sans le socle système et réseau qui décrochent le premier matin et ralentissent tout le groupe. Quand le résultat le justifie, une journée de remise à niveau préalable coûte bien moins cher qu’un sprint gâché.
Le bac à sable, ensuite. Chaque participant doit disposer de son propre abonnement, ouvert et vérifié avant la session, avec un budget plafonné et une date de suppression. Travailler à quatre sur un abonnement partagé transforme chaque exercice en négociation de nommage.
La question de départ, enfin. Nous demandons systématiquement au responsable une question réelle et non résolue : pourquoi la facture a augmenté de 40 % en un an, comment reconstruire l’environnement de recette après une panne, comment relier le site industriel au cloud sans exposer d’adresse publique. Cette question devient le fil rouge du parcours. Sans elle, la formation reste une visite guidée.
Le laboratoire doit ressembler à votre production
Un exercice cloud construit à partir d’un dossier vierge n’apprend presque rien, parce que personne ne travaille dans un dossier vierge. Ce que les équipes doivent savoir faire, c’est reprendre l’existant : un environnement construit à la main il y a deux ans, non documenté, par quelqu’un qui est parti.
Nos ateliers partent donc de cette situation. On importe dans le code de l’infrastructure des ressources créées manuellement, on constate l’écart entre l’état enregistré et la réalité, on nomme ce que l’on garde et ce que l’on reconstruit. On introduit volontairement une dérive de configuration entre deux exercices pour que les participants la détectent en revue de plan plutôt qu’en production.
Le même principe s’applique à la reprise d’activité. Un objectif de temps de reprise annoncé dans un document n’a aucune valeur tant qu’une bascule complète n’a pas été jouée, chronomètre en main, avec l’équipe qui la jouera réellement. La plupart des surprises n’apparaissent qu’à ce moment-là : une dépendance oubliée, un secret stocké nulle part ailleurs que dans la ressource détruite, une résolution de noms qui n’avait pas été prévue.
Le livrable de la semaine doit servir dès le lundi
Le meilleur indicateur de qualité d’une formation technique en intra-entreprise tient en une question posée au responsable trois semaines après : qu’est-ce qui est en production aujourd’hui et qui n’existait pas avant ?
Nous concevons donc chaque sprint autour d’un objet réutilisable : un module d’infrastructure décrivant le réseau central de l’entreprise, une alerte budgétaire réellement branchée, un tableau de bord de supervision qui remplace une surveillance manuelle, une procédure de restauration testée et datée. Ces objets sont produits en séance, revus par le formateur, et repartent dans le dépôt de l’entreprise.
C’est aussi ce qui rend le retour sur investissement discutable en comité de direction. « L’équipe a été formée à Terraform » ne se défend pas. « Le réseau central est décrit en code, l’environnement de recette se recrée en quelques dizaines de minutes au lieu de deux jours, et la facture mensuelle a baissé de tant après le redimensionnement fait en séance » se défend — à condition que chacun de ces trois chiffres ait été relevé chez vous, avant et après. Un chiffre repris d’une plaquette ne défend rien.
Mesurer autre chose que la satisfaction
Une bonne note de satisfaction dit que la formation s’est bien passée. Elle ne dit pas qu’elle a servi. Nous évaluons donc les acquis avant et après, sur les mêmes items, et nous revenons à 90 jours pour poser trois questions simples : ce qui a été mis en œuvre, ce qui a été abandonné, et pourquoi.
Le troisième point est le plus instructif. Le plus souvent, ce qui est abandonné ne l’est pas pour des raisons techniques mais organisationnelles : personne n’a arbitré le temps nécessaire, ou une seule personne détenait la compétence et a changé de poste.
L’erreur classique : ne former qu’une seule personne
C’est la fausse économie la plus fréquente. On envoie l’ingénieur le plus motivé, à charge pour lui de transmettre. Il ne transmet pas, parce que transmettre est un métier et parce qu’il n’en a pas le temps. Six mois plus tard, l’entreprise a une compétence, portée par une personne, indisponible dès qu’elle est en congés.
Le seuil utile est de deux personnes minimum sur un même sujet, trois si le service assure une astreinte. Le coût marginal du deuxième participant en intra est nul — le tarif s’applique à la journée, pour un groupe allant jusqu’à huit — et c’est la seule façon d’obtenir une revue de code d’infrastructure interne, donc une compétence qui se conserve.