Vibe Leader : La prochaine génération de tech leads

Chaque génération d’outils redéfinit la question de ce que signifie l’expertise. Le tableur n’a pas rendu les comptables obsolètes — il a rendu ce qu’impliquent les chiffres plus déterminant. Le traitement de texte n’a pas affaibli les écrivains — il a élevé ceux qui comprenaient ce qui méritait d’être dit.

Le développement assisté par IA a fait la même chose au génie logiciel. Les outils — GitHub Copilot, Cursor, Claude Code, et ce qui viendra après — ont automatisé la couche d’exécution du métier. Le code est généré plus vite qu’il ne peut être pleinement compris. Les tests sont écrits avant que la logique qu’ils vérifient soit entièrement réfléchie. Les ingénieurs livrent à des volumes qui étaient impossibles il y a deux ans.

Et quelque part dans cette accélération, le rôle du tech lead s’est silencieusement scindé en deux.

On a nommé ce qui s’est passé pour les ingénieurs. Le vibe coding. La pratique de diriger des outils IA pour générer du code, réviser le résultat par le jugement et l’intuition, livrer plus vite qu’une équipe n’aurait pu écrire. Ça s’est répandu largement. Des ingénieurs juniors produisant à des volumes qui nécessitaient autrefois de l’ancienneté. Des PR mergées que personne ne comprenait pleinement au niveau des lignes.

On n’a jamais nommé ce qui s’est passé pour les tech leads.

Jusqu’à maintenant.

Présentation du Vibe Leader

Un Vibe Leader n’est pas un vibe coder avec un titre.

Un Vibe Leader est ce que le rôle de tech lead devient quand l’IA gère la couche d’exécution : quelqu’un qui opère entièrement au niveau du jugement — au-dessus du code, là où le goût, le contexte et l’intuition architecturale remplacent la production comme mesure principale de la valeur.

Le mot vibe est délibéré. Pas vague. Pas décontracté. La vibe d’un système — la cohérence que l’on ressent quand chaque décision est consistante, quand l’architecture tient trois ans plus tard, quand un nouvel ingénieur peut lire la base de code et comprendre non seulement ce qu’elle fait mais pourquoi — est parmi les choses les plus difficiles à créer et les plus faciles à détruire. Elle ne peut pas être générée. Elle doit être cultivée.

Les Vibe Leaders la cultivent. Les vibe coders avec des titres l’érodent.

La distance entre ces deux groupes est la division la plus conséquente du leadership en ingénierie aujourd’hui. La plupart des organisations ne peuvent pas encore les distinguer. La plupart des référentiels de performance ne peuvent pas mesurer la différence. La plupart des tech leads n’ont pas encore décidé sur quel chemin ils s’engagent.

Cet article rend ce choix explicite.

Ce que le développement assisté par IA a réellement changé

Pour comprendre le Vibe Leader, il faut d’abord comprendre ce que les outils IA ont automatisé — et, surtout, ce qu’ils n’ont pas automatisé.

Les tech leads ont toujours tenu deux emplois simultanément. Ces emplois étaient rarement séparés assez clairement pour en parler distinctement, ce qui explique en partie pourquoi le changement a été si désorientant.

Le travail de production : Écrire et réviser du code. Débloquer les ingénieurs. Répondre à “comment faire X avec le framework Y”. Déboguer l’incident de production à 2h du matin. Réviser la PR que le junior a écrite sur le flux d’authentification.

Le travail de jugement : Décider quoi construire ensuite. Choisir l’architecture qui n’acculera pas l’équipe dans dix-huit mois. Dire non à la fonctionnalité qui semble simple mais ne l’est pas. Savoir quelle dette technique payer maintenant et laquelle différer. Construire les structures de confiance qui permettent à une équipe de livrer sans escalade constante.

Les outils de développement IA ont automatisé le travail de production. Presque complètement.

Ce que les outils IA gèrent aujourd'hui :
──────────────────────────────────────────────────────────────

Génération de code              ██████████████████████  90%+ automatisé
Boilerplate et scaffolding      ████████████████████    95%+ automatisé
Écriture de tests               ████████████████████    90%+ automatisé
Documentation                   ████████████████████    85%+ automatisé
Débogage des erreurs courantes  ██████████████████      80%+ automatisé
Descriptions de PR              ████████████████        75%+ automatisé
Questions sur les frameworks    ████████████████████    95%+ automatisé
"Comment fonctionne ce code"    █████████████████       80%+ automatisé

Ce qu'ils ne peuvent pas faire :
──────────────────────────────────────────────────────────────

Décider laquelle des trois architectures valides convient    ──  0%
Connaître la décision technique d'il y a 14 mois et pourquoi ──  0%
Sentir quand le périmètre d'un sprint devient ingérable      ──  0%
Construire la confiance qui permet à une équipe de s'auto-organiser ── 0%
Reconnaître quand la spec produit est le vrai bug            ──  0%
Comprendre les contraintes politiques sur les choix tech     ──  0%

Tout ce qui figure dans cette deuxième liste constitue désormais la fiche de poste complète du Vibe Leader.

Le travail de production n’a jamais été la vraie source de valeur d’un tech lead. C’était la partie la plus visible — celle qui générait un feedback immédiat, des ingénieurs reconnaissants, des artefacts mesurables. Les outils IA ont supprimé cette visibilité, ne laissant que la valeur. Et ce faisant, ils ont forcé chaque tech lead à soit opérer au niveau qui demeure, soit reconnaître qu’ils faisaient surtout la partie visible depuis le début.

C’est une réalisation déstabilisante. C’est aussi une réalisation clarifiante.

La scission : un titre, deux rôles complètement différents

Le titre de tech lead n’a pas disparu. Il s’est fracturé — en deux rôles qui se ressemblent de l’extérieur mais fonctionnent entièrement différemment, opérant à des niveaux distincts de la pile d’ingénierie.

LE RÔLE DE TECH LEAD AVANT LES OUTILS IA
──────────────────────────────────────

     ┌─────────────────────────────────────┐
     │             TECH LEAD               │
     │                                     │
     │  ● Écrire et réviser du code        │  ◄── Visible, feedback quotidien
     │  ● Débloquer les ingénieurs         │  ◄── Mesurable, immédiat
     │  ● Répondre aux questions tech      │  ◄── Héroïque, reconnu
     │  ● Déboguer les incidents prod      │  ◄── État avant/après clair
     │                                     │
     │  ● Décisions d'architecture         │  ◄── Invisible, feedback lent
     │  ● Jugement périmètre & risque      │  ◄── Difficile à mesurer
     │  ● Construction de la confiance     │  ◄── Nécessite des trimestres
     │  ● Préservation du contexte         │  ◄── Personne ne remarque jusqu'à disparition
     └─────────────────────────────────────┘


LE RÔLE DE TECH LEAD APRÈS LES OUTILS IA
──────────────────────────────────────

  ┌──────────────────────────┐    ┌──────────────────────────┐
  │  AUTOMATISÉ (outils IA)  │    │  VIBE LEADER (humain)    │
  │                          │    │                          │
  │  ● Génération de code    │    │  ● Architecture          │
  │  ● Écriture de tests     │    │  ● Jugement périmètre    │
  │  ● Documentation         │    │  ● Évaluation des risques│
  │  ● Boucles de débogage   │    │  ● Préservation contexte │
  │  ● Questions frameworks  │    │  ● Construction confiance│
  │  ● Descriptions de PR    │    │  ● Cohérence du système  │
  └──────────────────────────┘    └──────────────────────────┘

  La boîte gauche représentait environ 60% du travail visible.
  La boîte droite constitue désormais 100% de ce qui compte.

Le Vibe Leader habite entièrement la boîte droite. Il a abandonné la gauche — non pas parce qu’il manque de compétences, mais parce que le faire lui-même est maintenant le pire usage possible de son levier. Un chirurgien qui insiste pour stériliser ses propres instruments ne fait pas preuve d’engagement. Il mal-alloue la ressource la plus rare dans la salle d’opération.

La crise que personne n’a nommée

Voici l’argument structurel qui explique pourquoi le rôle de Vibe Leader n’est pas optionnel — il est porteur de charge.

Avant les outils IA, un IC senior typique produisait entre 200 et 500 lignes de code de production significatif par jour. Un tech lead révisant tout pouvait lire, comprendre et évaluer la totalité du delta entrant dans la base de code chaque semaine. Son modèle mental du système restait à jour.

Avec le développement assisté par IA, ce même IC produit entre 1 500 et 3 000 lignes par jour. La qualité des lignes individuelles est souvent plus élevée. Le code semble correct. Il a des tests. Il gère les cas limites. Il passe en revue.

L'ÉCART DE CAPACITÉ DE RÉVISION
────────────────────────────────────────────────────────────────

Avant les outils IA :

  Production IC quotidienne :   ████████  ~300 lignes/jour
  Capacité révision TL :        ████████  peut tout comprendre et réviser

Après les outils IA :

  Production IC quotidienne :   █████████████████████████████████  ~2 000 lignes/jour
  Capacité révision TL :        ████████  inchangée

                                  █████████████████████████
                                  Cet écart accumule
                                  de la complexité qu'aucun humain
                                  ne comprend pleinement.
                                  Invisible dans les métriques.
                                  Mais ça s'accumule chaque sprint.

Un tech lead qui tente de combler cet écart en révisant plus de code va échouer. Il n’y a pas assez d’heures. Le calcul n’est même pas proche. Le Vibe Leader le comble différemment — en contrôlant ce qui entre dans l’écart en premier lieu, grâce à un périmètre précis, une architecture explicite et une équipe qui comprend réellement le système qu’elle construit.

L’écart n’est pas un problème à résoudre en travaillant plus dur. C’est la condition permanente de l’ingénierie augmentée par l’IA. Le Vibe Leader existe parce que quelqu’un doit gérer l’espace entre ce que l’IA génère et ce que les humains comprennent réellement. Si personne n’assume ce travail, l’écart se remplit d’une complexité qui ressemble à du progrès — jusqu’à ce que ça ne soit plus le cas.

Les cinq disciplines du Vibe Leader

Le Vibe Leadership n’est pas un type de personnalité ni une disposition. C’est un ensemble de disciplines concrètes — chacune répondant directement à un manque que les outils IA ont créé au niveau inférieur.

Discipline 1 — La couche de jugement

Les outils de développement IA génèrent des solutions. Plusieurs solutions. Souvent quatre ou cinq approches plausibles, bien commentées, pour tout problème donné. Le goulot d’étranglement s’est déplacé de la génération vers l’évaluation.

La question n’est plus “quelqu’un peut-il écrire ça ?” C’est “parmi les approches que l’IA vient de produire, laquelle voulons-nous dans notre base de code dans trois ans ?”

LE GOULOT D'ÉTRANGLEMENT DÉPLACÉ
──────────────────────────────────────────────────────

Avant :  [Comprendre] → [Concevoir] → [Écrire] → [Réviser] → [Livrer]
                                         ↑
                                 goulot ici

Après :  [Comprendre] → [Concevoir] → [Générer] → [Évaluer] → [Livrer]
                                                      ↑
                                       Le Vibe Leader opère ici

Répondre à cette question d’évaluation requiert de savoir des choses qu’aucun outil IA ne saura jamais : ce que coûte la complexité quand on débogue à l’échelle, quelles abstractions ont tendance à fuir d’une façon visible seulement six mois plus tard, où sont les coutures organisationnelles qui rendent certaines solutions douloureuses à maintenir, ce que la forme actuelle de la base de code implique quant à la direction la moins coûteuse à étendre.

C’est le goût dans le sens le plus profond du terme. Pas une préférence esthétique, mais un jugement calibré construit à partir de cicatrices, de reconnaissance de patterns et d’une compréhension intime de comment ce système particulier, construit par cette équipe particulière, pour ce domaine particulier, a tendance à échouer. C’est la contribution principale du Vibe Leader — la chose qui ne peut pas être générée, seulement accumulée.

Discipline 2 — La garde du contexte

Les outils IA savent ce que dit le code. Ils n’ont aucun accès au pourquoi il le dit.

Ils ne savent pas que le service d’authentification est structuré ainsi à cause d’une exigence de conformité ajoutée au T3 de l’année dernière. Ils ne savent pas que LegacyUserAdapter existe à cause d’un client entreprise spécifique dont le contrat interdit les modifications d’API avec rupture. Ils ne savent pas que l’équipe a essayé la division microservices il y a dix-huit mois et l’a annulée après deux mois de difficultés opérationnelles.

LE GRADIENT DE CONTEXTE
────────────────────────────────────────────────────────────────

Haute    POURQUOI les décisions ont été prises
valeur   Contraintes non visibles dans le code
  │      Approches échouées et raisons de l'échec
  │      Contraintes politiques et organisationnelles sur les choix tech
  │
  │      ◄── Les outils IA n'ont aucun accès ici.
  │          Ça disparaît quand les gens partent.
  │          C'est le travail du Vibe Leader de le préserver et transmettre.
  │
Faible   CE QUE fait le code actuel
valeur   COMMENT il implémente chaque fonctionnalité
  │
  │      ◄── Les outils IA gèrent ça complètement.

À mesure que la génération de code s’accélère, les décisions sont prises plus vite — et le contexte nécessaire pour les prendre correctement devient plus critique, pas moins. Le POURQUOI s’accumule comme une connaissance institutionnelle invisible jusqu’à ce que quelqu’un parte en l’emportant avec lui, moment où il devient une dette technique invisible.

Le Vibe Leader rend le POURQUOI lisible : journaux de décisions, documents d’architecture, conversations d’équipe explicites où le raisonnement derrière les choix est énoncé et consigné. Dans un monde où le code est bon marché à générer, la chose la plus coûteuse dans le développement logiciel est de perdre le contexte qui explique pourquoi le système est structuré comme il l’est. Une base de code sans ce contexte n’est pas un actif. C’est un passif qui compile.

Discipline 3 — La définition du périmètre

Le rythme auquel le code peut être généré dépasse maintenant massivement le rythme auquel les exigences peuvent être clarifiées. C’est la nouvelle tension fondamentale dans la livraison logicielle.

LE PROBLÈME AMBIGUÏTÉ-VITESSE
────────────────────────────────────────────────────────────────

2024 (avant les outils IA) :

  Clarté des exigences :     ████████████░░░░  70% claire au début du sprint
  Vitesse d'implémentation : ██████░░░░░░░░░░  assez lente pour découvrir les lacunes
  Résultat : lacunes résolues avant de devenir du code de production

2026 (avec les outils IA) :

  Clarté des exigences :     ████████████░░░░  toujours 70% claire
  Vitesse d'implémentation : ████████████████  assez rapide pour dépasser les lacunes
  Résultat : lacunes gravées dans du code fonctionnel, testé, mergé
             qui doit maintenant être entièrement réécrit

Un ingénieur avec une assistance IA peut produire une implémentation fonctionnelle et testée d’une fonctionnalité ambiguë en une après-midi. Avant les outils IA, le temps d’implémentation était suffisamment long pour que l’ambiguïté remonte et soit résolue avant la fin du code. La friction était protectrice. Cette protection a disparu.

Le Vibe Leader est le limiteur de débit — non pas sur la production de code, mais sur l’ambiguïté entrant dans le pipeline de développement. Son travail est de définir le périmètre avec assez de précision pour que l’ingénieur augmenté par l’IA construise la bonne chose sans d’abord construire une mauvaise chose complète et fonctionnelle. Cela signifie écrire des critères d’acceptation assez spécifiques pour être falsifiables. Avoir la conversation “qu’est-ce que terminé signifie vraiment” avant le début du sprint. Être prêt à retarder un ticket deux jours pour clarifier la spécification plutôt que d’accepter une semaine de réécritures ensuite.

La définition du périmètre n’est pas un rituel de planification. C’est l’intervention principale qui détermine si un sprint produit de la valeur ou l’apparence de valeur.

Discipline 4 — La gestion du budget de complexité

Chaque système a un budget de complexité — une limite implicite sur la complexité structurelle qu’il peut absorber avant de devenir peu fiable et dangereux à modifier. Avant les outils IA, ce budget était géré, imparfaitement mais efficacement, par la friction d’écriture du code. Écrire du code complexe prenait du temps. Les ingénieurs devaient réfléchir aux implications. Le coût était un filtre naturel.

Les outils IA ont supprimé la friction. Écrire du code complexe est maintenant presque aussi rapide qu’écrire du code simple. Le contrôle naturel sur l’accumulation de complexité a disparu, et aucun nouveau contrôle ne l’a remplacé.

COMPLEXITÉ SANS GESTION ACTIVE
────────────────────────────────────────────────────────────────

Avant les outils IA :
│     ╭──────────────────────────  Croît, mais lentement.
│    ╭╯                            La friction naturelle limite le taux.
│───╭╯
└────────────────────────────────────────────────► temps

Après les outils IA (sans Vibe Leader) :
│                         ╭───────  Seuil gérable dépassé.
│                    ╭────╯         Système difficile à raisonner.
│               ╭────╯              Incidents de plus en plus difficiles.
│          ╭────╯
│─────╭────╯
└────────────────────────────────────────────────► temps

Après les outils IA (Vibe Leader actif) :
│     ╭──────╮ ╭──────╮            Simplification délibérée.
│    ╭╯       ╰╯       ╰──────╮    Complexité bornée.
│───╭╯                        ╰──  Système reste compréhensible.
└────────────────────────────────────────────────► temps

Le Vibe Leader gère activement le budget de complexité — décidant où la complexité est justifiée et où elle s’accumule sans raison suffisante. Cela signifie rejeter du code fonctionnel qui ajoute une complexité structurelle injustifiée, même s’il passe tous les tests. Cela signifie planifier une simplification explicite : traiter la complexité accumulée comme le défaut qu’elle est réellement, pas la fonctionnalité qu’elle semble être. Cela signifie construire une culture d’équipe où “ça fonctionne, mais c’est trop complexe” est une raison valable de livrer quelque chose de différent.

La gestion de la complexité est ingrate. Elle ne produit aucune nouvelle fonctionnalité. Elle ne ferme aucun ticket. C’est parmi les choses à plus fort levier qu’un Vibe Leader fait.

Discipline 5 — L’architecture de propriété

Quand les outils IA écrivent le code, qui en est propriétaire ? Pas légalement — pratiquement. Qui le comprend assez profondément pour le déboguer à 2h du matin ? Qui peut expliquer pourquoi il a été écrit de cette façon ? Qui sait ce qui va se casser si on le modifie ?

Dans de nombreuses équipes utilisant agressivement l’assistance IA, la réponse honnête est : personne.

L'ÉCART DE PROPRIÉTÉ
────────────────────────────────────────────────────────────────

Propriété saine :

  Module A  ──►  Ingénieur 1   compréhension profonde, peut modifier en sécurité
  Module B  ──►  Ingénieur 2   compréhension profonde, peut modifier en sécurité
  Module C  ──►  Ingénieur 3   compréhension profonde, peut modifier en sécurité

Équipe augmentée par IA sans Vibe Leader :

  Module A  ──►  IA + Ingénieur 1  │
  Module B  ──►  IA + Ingénieur 1  │ "Demander à l'IA" n'est pas
  Module C  ──►  IA + Ingénieur 1  │ de la propriété.
  Module D  ──►  IA + Ingénieur 2  │ Personne ne comprend pleinement
  Module E  ──►  IA + Ingénieur 2  │ les implications d'une modification.
  Module F  ──►  IA + Ingénieur 3  │

Le code qu’aucun humain ne comprend profondément est un passif déguisé en actif. Le fait qu’une IA puisse régénérer une explication à la demande ne constitue pas une propriété. Comprendre n’est pas récupérer. C’est la capacité de raisonner sur quelque chose — de prédire ses modes de défaillance, d’anticiper les conséquences des changements, de tenir sa logique en tête en modifiant un système adjacent.

Le Vibe Leader architecture la propriété : en s’assurant que pour chaque partie significative du système, au moins un humain la comprend réellement. Pas un humain qui peut demander à une IA de l’expliquer, mais un humain qui peut raisonner dessus de façon autonome. Cela requiert une attribution explicite de propriété, des pratiques de révision qui testent la compréhension plutôt que la simple correction, et une rotation délibérée qui construit la profondeur à travers l’équipe.

Ce qu’un Vibe Leader n’est pas

Il y a un mode d’échec qui se fait actuellement passer pour le Vibe Leader. Il a besoin de son propre nom.

Appelons-les des jockeys de curseur — des tech leads qui utilisent les outils IA pour faire encore plus du travail de production eux-mêmes, plutôt que de prendre du recul vers la couche de jugement. Leurs compteurs de commits sont impressionnants. Leur production visible est élevée. Ils se sentent productifs. Ils se présentent, dans chaque métrique que l’organisation suit actuellement, comme des performeurs élevés.

Pendant ce temps, les cinq disciplines ne sont pas exercées. Personne ne définit le périmètre avec assez de précision avant le développement. Le budget de complexité n’est pas géré. Le contexte institutionnel se dégrade. La propriété est diffuse.

JOCKEY DE CURSEUR vs VIBE LEADER
────────────────────────────────────────────────────────────────

Jockey de curseur (mode d'échec) :
  ● Utilise les outils IA pour livrer plus de code personnellement
  ● Révise les sorties IA pour la syntaxe et la correction
  ● Débogue les incidents avec l'assistance IA
  ● Compteur de commits élevé. Visible. Récompensé par les anciennes métriques.

  Manquant :
  ○ Définition de périmètre avant le développement
  ○ Gestion du budget de complexité
  ○ Préservation du contexte et documentation
  ○ Cultivation de la profondeur de propriété d'équipe
  ○ Cohérence architecturale à l'échelle du système

Vibe Leader (le rôle évolué) :
  ● Écrit rarement du code. Façonne fréquemment ce qui est écrit.
  ● Révise les sorties IA pour la solidité architecturale et le jugement
  ● Prévient les incidents par la clarté, pas l'héroïsme
  ● Compteur de commits faible. Invisible. Sous-évalué par les anciennes métriques.

  Livre :
  ✓ Des sprints qui se terminent parce que le périmètre était juste dès le départ
  ✓ Des systèmes qui restent compréhensibles en grandissant
  ✓ Des équipes qui s'auto-organisent parce que le contexte est préservé
  ✓ Des incidents qui ne se répètent pas parce que la propriété est claire

Le mode d’échec du jockey de curseur est séduisant parce qu’il produit une production immédiate et mesurable. Le travail du Vibe Leader est invisible jusqu’à ce qu’il ne soit pas fait — et à ce moment-là, l’équipe a passé un trimestre sur des réécritures que personne n’avait comptabilisées, un système que personne ne peut déboguer, un sprint qui s’est effondré parce que trois fonctionnalités ont touché le même module sans propriétaire.

L’ironie la plus profonde est que le jockey de curseur ressemble davantage à un tech lead, selon toutes les mesures traditionnelles, que le Vibe Leader. Les anciennes métriques ont été construites pour le travail de production. Le travail de production est maintenant automatisé. Les métriques n’ont pas rattrapé.

Une semaine dans la vie

Le Vibe Leader passe plus de la moitié de sa semaine à ne produire aucun code et à ne fermer aucun ticket. Il rédige des spécifications. Documente des décisions. A la conversation sur ce que “terminé” signifie vraiment avant que le développement commence. Identifie l’accumulation de complexité avant qu’elle ne devienne une crise.

Ce travail est invisible jusqu’à ce qu’il ne soit pas fait. Ce qui explique précisément pourquoi les organisations sous-investissent systématiquement dedans, et pourquoi les leaders qui le font sont chroniquement sous-évalués — jusqu’au trimestre où l’absence de leur travail devient évidente, sous forme de réécritures, d’incidents, de dérive architecturale que personne ne peut expliquer.

Le nouveau levier

Le Vibe Leader dispose de plus de levier que tout tech lead de l’ère pré-IA. Ce n’est pas une amélioration marginale. C’est un changement structurel dans la nature du leadership en ingénierie.

En 2023, un tech lead pouvait multiplier par 2 à 3 la production de son équipe grâce à un meilleur code et une révision plus fine. Son levier était limité par ses heures personnelles. Il était, fondamentalement, un producteur hautement qualifié qui s’ajoutait à la production totale de l’équipe.

En 2026, un Vibe Leader peut multiplier par 5 à 10 la production effective de son équipe — non pas en produisant davantage lui-même, mais en éliminant les frictions qui ralentissent les ingénieurs augmentés par l’IA. Chaque exigence ambiguë clarifiée avant le sprint évite deux jours de réécritures. Chaque décision architecturale prise explicitement et documentée clairement évite six semaines de dérive accumulée. Chaque lacune de propriété comblée évite un incident qui paralyse l’équipe pendant une semaine.

COMPARAISON DE LEVIER
────────────────────────────────────────────────────────────────

Tech Lead 2023 :

  Production = Σ(production IC) + code TL + qualité révision TL
               ─────────────────────────────────────────────────
               Additif. Limité par les heures personnelles.
  Multiplicateur : 1,5x – 3x

Vibe Leader 2026 :

  Production = Σ(IC × multiplicateur IA) × qualité jugement Vibe Leader
                                           ──────────────────────────────
                                           Multiplicatif. Non limité
                                           par les heures personnelles.
  Multiplicateur : 0,5x (mauvais jugement) → 10x (excellent jugement)

La relation est passée d’additive à multiplicative. Les enjeux ont changé en conséquence. Un Vibe Leader qui prend de mauvaises décisions architecturales les propage désormais à travers dix fois le volume de code. Un Vibe Leader qui définit clairement le périmètre livre désormais dix fois la bonne implémentation. Les boucles de feedback sont plus lentes, le rayon d’action est plus large dans les deux sens, et l’exigence irréductible d’un vrai jugement — pas de processus, pas de production, du jugement — n’a jamais été aussi élevée.

Comment reconnaître un Vibe Leader

Les organisations mesurent les mauvaises choses.

Elles regardent la vélocité des sprints. Les taux de fermeture de tickets. Le délai de révision du code. Les taux de merge des PR. Ce sont des métriques de l’ère pré-IA — conçues pour capturer le travail de production, qui est maintenant automatisé. Les utiliser pour évaluer les Vibe Leaders revient à mesurer la valeur d’un chirurgien au nombre de scalpels qu’il a nettoyés.

Le travail du Vibe Leader n’a pas de métriques natives. On ne peut pas mettre “cohérence architecturale maintenue ce trimestre” dans une évaluation de performance avec un chiffre à côté. On ne peut pas quantifier la préservation du contexte.

Cela crée un écart d’évaluation dangereux. Les Vibe Leaders semblent moins productifs selon les anciennes mesures. Les jockeys de curseur semblent plus productifs. Avec le temps, les organisations optimisent pour le mauvais rôle et se demandent pourquoi leurs équipes augmentées par l’IA continuent à produire une vélocité impressionnante et des résultats décevants.

La question que chaque leader en ingénierie devrait se poser : Si le volume de code généré par IA de notre équipe triplait demain, la qualité du jugement qui le sous-tend évoluerait-elle proportionnellement ?

Si la réponse est non — si la couche de jugement ne croît pas aussi vite que la couche de code — alors l’écart entre ces deux taux est le risque qui s’accumule invisiblement dans le système. Aucun tableau de bord ne vous le montre.

Signes que votre équipe a un Vibe Leader :

• Les sprints se terminent de façon constante parce que le périmètre est bien défini avant de commencer
• Les nouveaux ingénieurs peuvent lire la base de code et comprendre le pourquoi, pas seulement le quoi
• Les incidents sont rares ; quand ils surviennent, ils sont diagnostiqués rapidement parce que la propriété est claire
• Les décisions architecturales d’il y a 18 mois ont encore du sens aujourd’hui
• Le tech lead est rarement dans les sessions de débogage mais souvent dans les sessions de spécification

Signes que votre équipe a un jockey de curseur :

• Vélocité élevée des PR mais réécritures fréquentes de fonctionnalités récemment livrées
• Incidents récurrents dans les mêmes modules
• Les nouveaux ingénieurs ne peuvent pas modifier le code avec confiance sans assistance IA pour l’expliquer
• L’architecture dérive fonctionnalité par fonctionnalité sans que personne ne remarque jusqu’à ce que ce soit une crise
• Le tech lead est la personne la plus occupée de l’équipe — et l’équipe en dépend

Devenir un Vibe Leader

Si vous êtes actuellement tech lead et que les outils IA ont intégré le workflow de votre équipe, la question pratique est de savoir quoi faire différemment à partir de lundi.

Arrêtez de concurrencer sur la production. Vous ne battrez pas un outil IA à l’écriture de code. Vous ne battrez pas une équipe augmentée par l’IA en révision. Tenter de le faire n’est pas de la productivité — c’est de l’évitement. Dès que vous abandonnez la production comme contribution principale, la couche de jugement devient accessible.

Écrivez le POURQUOI explicitement. Chaque décision technique significative prise cette semaine devrait avoir un enregistrement écrit — pas une description de PR, mais un document de décision. Pourquoi cette approche plutôt que les alternatives. Quelles contraintes l’ont façonnée. Quels sont les compromis connus. C’est le contexte qu’aucun outil IA n’aura jamais et dont les futurs ingénieurs auront désespérément besoin.

Possédez le périmètre du sprint, pas les tickets. Votre travail est de vous assurer que chaque ticket entrant dans un sprint est défini avec assez de précision pour qu’un ingénieur augmenté par l’IA puisse construire la bonne chose sans d’abord construire la mauvaise. C’est un travail différent que de choisir des tickets ou d’estimer des story points.

Planifiez la simplification. Chaque sprint devrait inclure une capacité explicite pour éliminer la complexité, pas seulement ajouter des fonctionnalités. Faites-en une ligne budgétaire. Donnez-lui un propriétaire. Traitez la complexité accumulée comme le défaut qu’elle est réellement.

Assignez la propriété explicitement. Pour chaque module significatif, il devrait y avoir un humain nommé qui le comprend profondément — pas qui l’a écrit, pas qui l’a dernièrement touché, mais qui en est actuellement propriétaire en compréhension suffisante pour le modifier en sécurité. Publiez cette liste. Mettez-la à jour quand elle change.

Le Vibe Leader n’est pas un nouveau concept — c’est un ancien enfin rendu visible

Les meilleurs tech leads faisaient toujours ce travail. Ils opéraient toujours au niveau du jugement — gardant le contexte, définissant le périmètre précisément, gérant la complexité délibérément, construisant une propriété genuine à travers leurs équipes. Le travail de production était une interruption constante du vrai travail, déguisée en vrai travail parce que c’était la partie que l’on pouvait voir.

Ce qui a changé, c’est que les outils IA ont fait disparaître la couche d’exécution. Et avec elle, la visibilité des leaders qui faisaient le travail plus profond depuis le début.

Le Vibe Leader n’est pas un rôle inventé par les outils IA. C’est le rôle de tech lead avec l’échafaudage retiré. Ce qui reste est la structure porteuse qui maintenait tout en place pendant que les gens se concentraient sur l’échafaudage.

Maintenant que l’échafaudage a disparu, tout le monde peut voir la structure.

Il y a une version de ce moment qui est clarifiante. Les meilleurs leaders — ceux qui opéraient toujours au niveau du jugement — sont soudainement visibles d’une façon qu’ils ne l’ont jamais été. Leur valeur n’est pas déplacée. Elle est révélée.

Il y a une autre version qui est déstabilisante. Les leaders qui ont construit leur identité autour du travail de production réalisent que l’échafaudage qu’ils entretenaient a été automatisé, et ce qui reste est la question plus difficile de savoir s’ils ont jamais, vraiment, fait le travail en dessous.

Les deux versions se produisent simultanément. Dans les équipes, dans les organisations, dans l’industrie — maintenant.

La question est de savoir laquelle vous décrit.

Écrit par Neel Shah — Tech Lead & Ingénieur de données senior, Ottawa. Vous construisez une équipe qui a besoin d’un Vibe Leader ? Parlons-en : hire@neelshah18.com