Équipe tech à l'ère de l'IA
Décider, cadrer, embarquer
Formation 2 jours pour CTO, tech leads et responsables d'équipe technique : prendre position sur l'IA dans ton organisation, poser un cadre d'usage, et embarquer une équipe divisée.
Le symptôme
« Ils font ça avec 4 développeurs. On en a 11. »
Le message est arrivé samedi soir. Un lien vers un article, et cette phrase.
Tu ouvres ton ordinateur lundi matin en sachant que la conversation aura lieu jeudi, et tu fais l'inventaire de ce que tu as vraiment sous les yeux.
Deux développeurs produisent trois fois plus qu'avant. Personne ne relit sérieusement ce qu'ils livrent, parce que le volume a dépassé la capacité de revue de l'équipe. Trois refusent d'utiliser quoi que ce soit, et ils ont des arguments que tu ne sais pas réfuter. Un junior arrivé il y a huit mois n'a jamais eu à déboguer seul, et tu commences à te demander ce qu'il saura faire dans deux ans. Les cinq autres utilisent, discrètement, sans en parler en réunion.
Tu n'as ni chiffres, ni règles, ni position.
Jeudi, on va te demander pourquoi vous n'allez pas trois fois plus vite. Et la seule réponse dont tu disposes aujourd'hui commence par « c'est plus compliqué que ça ».
Le prix de l'inaction
Ce que ça te coûte, concrètement
Tu subis une injonction que tu ne sais pas objectiver.
Tu ne peux ni confirmer les gains annoncés, ni les réfuter, ni dire ce qu'ils coûtent ailleurs. Sur ce terrain, la conversation avec le dirigeant se termine toujours mal.
Ton équipe se divise en silence.
Deux camps se forment, personne n'en parle ouvertement, et la tension se déplace vers les revues de code, les estimations et les rétrospectives. Ces conflits deviennent très difficiles à traiter une fois qu'ils se sont installés sous une autre forme.
Tu perds la visibilité sur ce qui est produit.
Il sort davantage de code, et une proportion croissante de ce code n'a été comprise en profondeur par personne. La conséquence n'apparaît pas ce trimestre. Elle apparaît le jour d'un incident sérieux.
Tes juniors n'apprennent plus de la même façon.
Le chemin classique passait par la galère, l'erreur et le débogage. Ce chemin a changé, personne ne l'a remplacé, et c'est la génération de seniors de 2030 qui se joue là.
Tu décides par défaut.
Ne rien trancher est une décision, et c'est celle qui te fait perdre la main sur les pratiques de ton équipe.
Ce que ça change
Ce que tu gagnes
Une position tenable devant ton dirigeant.
Documentée, chiffrée en ordres de grandeur, avec ce qui est réellement gagné, ce qui ne l'est pas, et ce que le gain coûte ailleurs dans la chaîne.
Une équipe qui parle du sujet.
Les objections des sceptiques sont mises sur la table et traitées pour ce qu'elles sont, c'est-à-dire souvent des objections justes. C'est la condition pour éviter la fracture durable.
Un cadre d'usage explicite.
Ce qui peut être délégué, ce qui ne l'est jamais, ce qui doit être relu et comment, ce qui ne sort pas de l'entreprise. Écrit, discuté, révisable.
Un modèle d'apprentissage pour les juniors.
Adapté au contexte actuel, qui préserve la construction des réflexes que la machine ne construit pas.
Des critères de recrutement à jour.
Parce que le profil qui crée de la valeur dans une équipe technique aujourd'hui n'est plus tout à fait celui que tes grilles d'entretien évaluent.
Une organisation qui absorbe la vague suivante.
Le sujet va continuer de bouger. Ce qui se transmet ici, c'est une méthode de décision, pas un état de l'art qui sera périmé dans six mois.
Profil
Pour qui
Également les CTO freelances et fractional CTO qui doivent poser ce cadre chez leurs clients, souvent en quelques semaines et sans autorité hiérarchique.
Il faut avoir une responsabilité, même informelle, sur les pratiques d'une équipe de développement, et une expérience réelle du développement logiciel.
Ce n'est pas fait pour toi si
tu cherches une formation au prompt engineering, un panorama comparatif d'outils, ou de la mise en pratique sur assistants de code. Ici, on travaille la décision, le cadre et la conduite du changement.
La méthode
Les grandes étapes
Les bases utiles pour décider
Ce que ces systèmes font, ce qu'ils ne font pas, et pourquoi. Le niveau visé est celui qui permet d'arbitrer, pas de construire : capacités réelles et modes d'échec, confidentialité et propriété du code, structure des coûts, et surtout ce qui bouge tous les trimestres versus ce qui reste stable plusieurs années.
Ce qui change réellement dans le travail
On passe le cycle complet au crible : cadrage, conception, écriture, revue, test, débogage, documentation, maintenance. Le gain est spectaculaire à certaines étapes et nul à d'autres : il déplace le goulot d'étranglement plutôt qu'il ne le supprime. Savoir où il s'est déplacé rend ton discours crédible.
La transformation du rôle de développeur
Quand la production de code perd de sa valeur relative, la valeur se déplace vers le jugement, l'arbitrage et la vérification. On travaille les conséquences concrètes : quelles compétences montent, lesquelles descendent, ce que devient la séniorité, et ce que ça impose de changer dans tes grilles d'entretien.
Embarquer une équipe divisée
Le cœur de la formation. Les trois postures qu'on rencontre systématiquement (l'enthousiaste, le sceptique, le silencieux) et ce qu'il faut à chacune. Comment traiter les objections de fond, qui méritent une vraie réponse. Pourquoi l'adoption par décret échoue, et le cas particulier du senior respecté qui refuse.
Poser le cadre d'usage
La règle écrite qui remplace le flou : ce qu'on délègue et à quelles conditions, ce qui ne sort jamais de l'entreprise, qui est responsable en cas de problème. On travaille aussi comment construire ce cadre avec l'équipe plutôt que contre elle.
Piloter et rendre compte
Quoi observer pour savoir si ça marche, et quels indicateurs éviter. Comment mener la conversation avec un dirigeant qui attend un facteur trois, et faire évoluer le cadre sans repartir d'une page blanche à chaque fois.
La mise en pratique
L'exercice de la formation
Tu repars avec deux choses produites pendant la formation, sur ton contexte réel.
La politique d'usage de ton équipe, rédigée et argumentée, prête à être soumise en interne : le groupe la challenge en jouant les objections de tes propres développeurs. Et la conversation avec ton dirigeant, simulée avec la question sur la productivité attendue : tu la joues, tu reçois les retours du groupe, tu la rejoues.
C'est le passage le plus exigeant de la formation, et celui dont les participants disent qu'il change le plus leur semaine suivante.
Livrables
Tu repars avec :
Tarif
Format et tarif
2 jours
1 800 € HT
Le parcours complet : bases, transformation du travail et du rôle, conduite du changement, cadre d'usage, pilotage.
3 jours
2 700 € HT
Une journée supplémentaire de mise en pratique approfondie sur les situations réelles des participants : diagnostic de sa propre équipe, construction du plan de déploiement sur six mois, simulations de conversations difficiles avec les développeurs comme avec la direction.
Pédagogie volontairement pratique : apports courts, travail sur ta propre équipe, jeux de rôle, production de tes supports et feedback collectif.
Questions fréquentes
Les questions qu'on nous pose
« C'est plus compliqué que ça. »
« Le gain est net sur le cadrage et l'écriture, je peux le documenter. Sur la revue, on en a repris une partie, et voici pourquoi. Voilà nos règles, ce qui débloquerait vraiment la vitesse, et ma recommandation sur l'effectif. »
Le même sujet. Une conversation que tu diriges, au lieu d'une conversation que tu encaisses.