L'Act 2 de GitLab - La restructuration agentique passe au grand jour

Bill Staples a publié une lettre le 11 mai qui sera, je pense, citée pendant des années. GitLab, entreprise cotée à un rythme d’ARR de plus d’un milliard de dollars, vient de mettre tout son operating model dans la centrifugeuse : trente pour cent de pays en moins, trois niveaux de management supprimés dans certaines fonctions, près de soixante empowered teams R&D plus petites remplaçant la structure précédente, des processus internes recâblés avec des agents, le framework de valeurs CREDIT, vieux de longue date, retiré au profit de trois nouveaux principes opérationnels, et une reconstruction générationnelle de l’infrastructure sous-jacente, y compris Git lui-même. Ils n’attendent pas que l’ère agentique arrive. Ils misent opérationnellement l’entreprise sur le fait d’être déjà à l’intérieur d’ici au 1er juin.

J’écris sur cette transition depuis six mois à travers une série d’articles - la thèse de l’empowerment, le vibe coding en prod comme problème de management, le skills framework, l’architecture IA à trois niveaux, le dernier goulot d’étranglement. La lettre de Staples est, en un seul document, la version la plus publique et la plus concrète de chaque argument de cette série. La lire m’a donné l’impression de regarder un CEO lire mon brouillon et le transformer en décision de bilan.

Voilà à quoi ressemble réellement la restructuration agentique quand une entreprise cotée la mène à découvert. La lettre vaut d’être lue de bout en bout. Cet article est ma synthèse : ce que GitLab a fait, ce que ça nous dit sur la direction que prend le reste du marché, et ce que ça valide - et ce que ça met en risque - dans le playbook des empowered teams appliqué à cette échelle.

Ce que GitLab a vraiment annoncé

La lettre est partagée entre une réorganisation opérationnelle et une thèse stratégique. Elles sont volontairement séparées, même si la presse va les confondre. Les deux méritent d’être comprises séparément.

Les mouvements opérationnels

1. Empreinte pays réduite jusqu’à 30% là où les équipes sont sous-dimensionnées. Les clients de ces marchés seront servis par des partenaires.
2. Jusqu’à trois niveaux de management supprimés dans certaines fonctions, parce que “huit niveaux, c’est trop profond pour une entreprise de notre taille, et les couches de management nous ralentissent.”
3. R&D reconstruite en environ 60 empowered teams plus petites avec une ownership end-to-end. Cela double presque le nombre d’équipes indépendantes.
4. Processus internes recâblés avec des agents IA, automatisant reviews, approbations et handoffs.
5. Un processus de restructuration transparent avec une fenêtre de départ volontaire jusqu’au 18 mai, finalisée au plus tard le 1er juin.

La thèse stratégique : dix convictions de fond

Le monde pour lequel ils construisent :

1. Le logiciel sera construit par des machines, dirigé par des humains. Les agents planifient, codent, relisent, déploient et réparent. Les humains possèdent l’architecture, la compréhension du problème client, et les arbitrages qui demandent du goût.
2. L’ère agentique multiplie la demande de logiciel. La dépense plateforme développeur passe de quelques dizaines de dollars par utilisateur par mois à plusieurs centaines, en route vers les milliers.
3. Le travail conséquent revient aux ingénieurs. Les résolveurs de problèmes capables de raisonner à travers l’ambiguïté, les systèmes distribués et les risques d’intégration deviennent le talent le plus rare et le plus précieux.

Les paris architecturaux :

4. Infrastructure à l’échelle machine. Git lui-même est en cours de réingénierie, le monolithe cède la place à des services composables API-first, des APIs spécifiques aux agents comme citoyens de première classe.
5. Orchestration sur tout le cycle de vie. CI/CD réimaginé comme le runtime qui coordonne les agents, valide le travail et applique les garde-fous au rythme machine.
6. Le contexte comme superpouvoir. Un modèle de données connecté couvrant planification, code, review, sécurité, déploiement et opérations, exposé comme un service API-accessible de première classe.
7. Gouvernance intégrée au cœur. Identité, audit, policy, et flexibilité de déploiement comme services plateforme cœur, pas comme add-ons.
8. Une plateforme, trois modes. Travail human-owned, agent-assisted, et agent-autonomous, neutre vis-à-vis du cloud et du modèle.

Comment ils vont livrer :

9. Un modèle économique flexible. Abonnements plus pricing à la consommation, avec plus de mélange à mesure que le travail évolue.
10. Une culture de l’excellence. Trois nouveaux principes opérationnels : Speed with Quality, Ownership Mindset, Customer Outcomes.

C’est tout le cadre. Voici ce que j’en pense.

Voilà des Empowered Teams à plus d’un milliard d’ARR

La phrase la plus importante de toute la lettre, pour moi, est enterrée dans les mouvements opérationnels : “réorganiser la R&D pour créer environ 60 équipes plus petites, plus empowered, avec une ownership end-to-end, doublant presque le nombre d’équipes indépendantes.”

Si vous avez lu mon article précédent sur diriger l’IA comme problème d’empowerment, vous le verrez immédiatement. Marty Cagan plaide depuis deux décennies que la taille et la forme de l’équipe sont le premier levier qu’une organisation produit doit actionner. Les empowered teams - petites, durables, cross-functional, propriétaires d’un problème plutôt que d’un backlog de features - sont la façon dont les bonnes entreprises produit avancent vite à l’échelle. EMPOWERED, le livre, est sur l’étagère de tout CPO raisonnable depuis 2020.

Ce que GitLab vient de faire, c’est la réalité opérationnelle derrière cette étagère. Doubler presque le nombre d’équipes indépendantes n’est pas un jeu de coûts. Les jeux de coûts consolident. Les jeux d’empowerment multiplient. Vous ne faites ce mouvement que si vous croyez que l’unité productive de l’ère agentique est la petite équipe autonome, pas la grande org coordonnée. “Les personnes les plus proches du travail prennent les décisions qui le concernent, et elles en possèdent le résultat. Les couches de management entre les dirigeants et le travail produit, et les handoffs qui diluent la responsabilité, sont éliminés.” C’est Staples qui écrit la même ligne que Cagan et Hastings ont écrite, mais maintenant comme principe opérationnel d’une entreprise cotée.

L’aplatissement - retirer jusqu’à trois niveaux de management - est le mouvement dual. On ne peut pas faire tourner soixante empowered teams à travers huit niveaux de management. Les maths ne tiennent pas et la latence ne survit pas. Si vous voulez du context-not-control, vous devez supprimer la surface de contrôle, pas juste refuser de l’utiliser. C’est ce que veut dire plus plate, en pratique.

Je vais surveiller ça de près parce que c’est la validation la plus visible à ce jour de la thèse des empowered teams à l’ère IA. Si ça marche, chaque autre CEO de dev tools, d’infra et de SaaS sera en board call dans le trimestre à expliquer pourquoi il ne fait pas la même chose.

Le logiciel sera construit par des machines, dirigé par des humains

La conviction 1 sur les dix est celle qui porte tout le reste : “Le logiciel sera construit par des machines, dirigé par des humains.” C’est exactement la thèse sur laquelle je travaille, juste avec un verbe plus confiant. Le cadrage d’Eric Schluntz dans sa conférence sur le vibe coding était oublie le code, pas le produit. Le cadrage de Kief Morris dans l’article Fowler était sois on the loop, pas in the loop. Le cadrage de Bill Staples est la version exécutive des deux : les machines font le travail, les humains le dirigent.

La distinction que Staples dessine ensuite est importante et je veux la signaler parce que la plupart des lecteurs entreprise vont la survoler :

Les humains possèdent toujours le jugement qui compte le plus : architecture, compréhension profonde du problème client, les arbitrages qui demandent du goût.

C’est le cadrage d’empowerment pleinement intériorisé. Le rôle humain n’est pas réduit - il est concentré aux points de plus fort levier : architecture, jugement, insight client et goût. C’est exactement le “travailler sur des problèmes plutôt que sur des solutions” de Cagan appliqué à l’ère agentique. Les ingénieurs et product managers capables de faire le travail conséquent deviennent plus précieux, pas moins. Ceux qui ajoutaient de la valeur en étant un dactylo rapide ou un relecteur attentif de diffs évidents, non. C’est l’inflexion de talent density que Reed Hastings avait prévenue, arrivant à l’heure prévue.

Les paris architecturaux sont chacun plus gros qu’il n’y paraît

Les cinq paris architecturaux de la lettre méritent leur propre lecture. Trois d’entre eux en particulier sont plus gros que leurs bullet points ne le laissent croire.

Infrastructure à l’échelle machine : reconstruire Git

Celui-là est audacieux jusqu’à l’audace pure. GitLab dit publiquement que Git lui-même est en cours de réingénierie pour l’échelle machine. Pas des services wrapper autour de Git, pas du Git par-dessus, pas de nouvelles APIs autour de Git. Git lui-même. Le raisonnement tient : les agents ouvrent des MR en parallèle, déclenchent des pipelines en continu, poussent des commits à la cadence machine. Les hypothèses de conception de 2005 sur la cadence humaine des commits ne survivent pas à cette charge. Si vous êtes une entreprise qui fait tourner cent agents en parallèle, vous le découvrez à la dure dès le premier mois.

C’est le genre de pari qui ne fait sens que si vous croyez profondément à la conviction 1. Si vous croyez que les agents vont faire l’essentiel de la construction, alors le substrat doit être reconstruit pour absorber cela. Le moat compétitif créé par le fait d’être la plateforme qui gère le travail à cadence agent par défaut, pendant que tout le monde colle de l’IA sur un Git de forme humaine, est énorme s’ils y arrivent.

Le contexte comme modèle de données connecté

La conviction 6 est celle que j’ai dû lire deux fois. “Ce qui ne se commoditise pas, c’est le contexte unique avec lequel le modèle peut travailler : un modèle de données qui connecte planification, code, review, sécurité, déploiement et opérations à travers chaque projet et chaque repository, accumulé sur des années de travail d’équipe.”

C’est GitLab qui réalise qu’il possède un dataset longitudinal qu’aucun lab IA ne peut répliquer. OpenAI peut entraîner un meilleur modèle. Anthropic peut entraîner un meilleur modèle. Aucun des deux ne peut synthétiser cinq ans des données planification-vers-production de votre entreprise. La plateforme qui possède le graphe connecté gagne la bataille de l’efficacité agent, même si les modèles sous-jacents se commoditisent. C’est, à mon avis, l’insight le plus profond de toute la lettre. Cela explique aussi pourquoi chaque entreprise de dev tools qui a fragmenté planification, code, review et ops en produits séparés est soudainement en bien pire posture qu’elle ne le réalise.

Une plateforme, trois modes

La troisième conviction que je veux signaler, c’est “une plateforme, trois modes” - human-owned, agent-assisted, agent-autonomous. C’est la seule forme réaliste des cinq prochaines années. Quiconque vous dit que tout le logiciel devient pleinement autonome demain vous vend quelque chose. Quiconque vous dit que rien d’important ne sera agent-autonomous dans deux ans vous vend aussi quelque chose. La vérité est ce que chaque CTO d’entreprise sait déjà : vous aurez un portefeuille de modes à travers votre codebase, et la plateforme qui gère les trois avec le même modèle de données et la même gouvernance gagne. C’est la même structure logique que le cloud hybride, quinze ans plus tard, appliquée à l’axe humain-agent au lieu de l’axe on-prem-cloud.

Les principes opérationnels sont l’opérationnalisation culturelle

Staples a retiré CREDIT, le framework de valeurs de longue date de GitLab, et l’a remplacé par trois nouveaux principes opérationnels :

1. Speed with Quality
2. Ownership Mindset
3. Customer Outcomes

Chacun est déplié avec des attentes comportementales. Les listes complètes sont dans la lettre et valent d’être lues, mais je veux mettre en lumière la ligne de Speed with Quality qui résume toute la thèse empowered-team-meets-agentic-era en un seul bullet :

Si un agent peut le faire, on l’automatise, et on cherche les endroits où notre jugement ou notre savoir-faire est essentiel.

C’est la discipline du harness de Morris, l’esprit des empowered teams de Cagan, et la règle proposée par Schluntz - tout en un seul bullet point que chaque employé GitLab est désormais censé opérationnaliser au quotidien. Trouvez les leaf nodes, automatisez-les, et concentrez l’attention humaine sur ce qui en a vraiment besoin. C’est le principe opérationnel de la prochaine décennie d’entreprises logicielles, articulé comme une règle de culture plutôt qu’une règle d’architecture.

Le bullet Ownership Mindset - “Ce n’est jamais le problème de quelqu’un d’autre” - et le bullet Customer Outcomes - “Mon travail crée de la joie et du plaisir pour les clients afin qu’ils aiment GitLab” - sont d’anciens principes d’empowered teams, et ils se lisent comme EMPOWERED et No Rules Rules condensés en rituels d’équipe. Tant mieux. Les principes qui comptent sont ceux qui survivent à travers les ères. L’ère IA ne les remplace pas, elle aiguise le coût de ne pas vivre selon eux.

Ce que je trouve risqué

Je ne suis pas sycophante face à ce genre de mouvement et l’article n’est utile que s’il dit aussi ce sur quoi je pousserais en retour. Trois risques qui méritent d’être nommés honnêtement :

1. Le tradeoff de la transparence

Staples fait ça de manière transparente avec une fenêtre de départ volontaire. C’est sincèrement admirable et probablement éthiquement le bon choix, mais cela porte un vrai coût d’exécution : plusieurs semaines d’incertitude sur l’ensemble de la workforce pendant que la planification est en cours, avec les personnes les mieux placées pour partir étant précisément celles qu’un Act 2 gagnant doit garder. Le Keeper Test de No Rules Rules est le bon cadre : les hauts performeurs peuvent toujours partir, et une longue fenêtre d’incertitude plus un package volontaire vont accélérer les départs de personnes qu’on ne peut pas se permettre de perdre. La version honnête de ce risque, c’est que le processus transparent est cher en talent density, et le pari est que les gains en confiance pèsent plus lourd que ces pertes. Je pense que Staples a probablement raison, mais ce n’est pas gratuit.

2. Reconstruire Git pendant que les clients dépendent de vous

La conviction 4 engage sur une reconstruction générationnelle de l’infrastructure sous-jacente - Git lui-même, le monolithe, des APIs agent-first - “sans perturbation pour les clients GitLab qui dépendent de nous chaque jour.” C’est la version platform engineering du changement de moteurs en plein vol. Tout CPTO qui a livré une refonte d’infra générationnelle connaît le mode d’échec : les timelines glissent, l’ancienne surface continue de consommer la capacité d’ingénierie, et la nouvelle surface livre dix-huit mois en retard avec des trous fonctionnels qu’on avait promis aux clients. Le fait qu’ils mentionnent explicitement aucune perturbation est juste, mais c’est la phrase la plus difficile à honorer de toute la lettre.

3. Right-sizer les rôles avant que le harness soit prouvé

La conviction 4 des mouvements opérationnels - “recâbler les processus internes avec des agents IA, automatiser les reviews, approbations et handoffs pour nous accélérer, et prévoir de right-sizer les rôles dans toute l’entreprise pour suivre” - est le mouvement qui doit arriver, mais l’ordre compte. La leçon la plus dure de l’ingénierie agentique à l’échelle, c’est que le harness doit être construit et prouvé avant qu’on retire les humains dont le jugement absorbait précédemment les trous du harness. Right-sizer trop tôt crée le même mode d’échec que j’ai décrit dans vibe coding en prod - la dette se compose là où personne ne regarde parce que la couche de vérification n’avait pas encore été construite. Je fais confiance à la culture d’ingénierie de GitLab pour gérer ça, mais c’est l’endroit où tout ce programme pourrait glisser discrètement de l’empowerment agentique vers le sous-effectif agentique. Le mot d’ordre, c’est prouver le harness, puis redimensionner.

Ce que ça valide

En prenant du recul, qu’est-ce que cette lettre valide à propos de tout ce qu’on écrit ?

Affirmation des articles précédents	Ce que dit l’Act 2 de GitLab
Les empowered teams sont l’unité productive de l’ère agentique	”Environ 60 équipes plus petites, plus empowered, avec une ownership end-to-end, doublant presque le nombre d’équipes indépendantes.”
Les organisations plates battent les organisations en couches une fois les agents dans la boucle	”Jusqu’à trois niveaux de management” supprimés
Le contexte, pas le contrôle, est la posture de leadership	”Les personnes les plus proches du travail prennent les décisions qui le concernent, et elles en possèdent le résultat.”
Le goulot d’étranglement humain est à l’architecture et au jugement, pas à la code review	”Les humains possèdent toujours le jugement qui compte le plus : architecture, compréhension profonde du problème client, les arbitrages qui demandent du goût.”
La vérifiabilité et le harness, pas l’inspection, sont la façon de manager les agents à l’échelle	Orchestration comme runtime, gouvernance intégrée au cœur
Le contexte connecté et longitudinal est le vrai moat	”Le contexte est ce qui permet aux agents de dépenser moins de tokens et de livrer de meilleurs résultats.”
Leaf nodes et troncs - automatiser là où on peut, concentrer les humains là où ils comptent	”Si un agent peut le faire, on l’automatise, et on cherche les endroits où notre jugement ou notre savoir-faire est essentiel.”

Si vous m’aviez dit il y a six mois qu’un CEO de dev tools coté allait livrer la version mono-document la plus propre de chaque argument que je suis en train de défendre, j’aurais été poli à ce sujet. Staples l’a fait le 11 mai. La presse couvrira la réduction de workforce. La presse sous-couvrira la thèse stratégique, qui est la partie qui compte pour la prochaine décennie.

Ce que je vais voler

Il y a trois mouvements opérationnels dans cette lettre que je vais voler pour le rôle de CPTO londonien que je suis sur le point de prendre :

1. Principes opérationnels, pas valeurs. GitLab retirant CREDIT au profit de Speed with Quality, Ownership Mindset, Customer Outcomes est la bonne forme de mouvement. Les frameworks de valeurs décrivent qui nous sommes. Les principes opérationnels décrivent comment on travaille. L’ère agentique récompense le second cadrage, parce que “si un agent peut le faire, on l’automatise” est une règle opérationnelle sur laquelle on peut agir dans un daily standup. “Nous sommes ouverts” est une valeur qui requiert interprétation. Je veux des principes opérationnels, scopés serrés, avec des comportements concrets, sur lesquels on peut se tenir.
2. Empowered teams right-sized, dès le jour un. Je ne vais pas scaler vers des empowered teams. Je vais commencer là. Petites, durables, cross-functional, propriétaires d’un problème, avec le harness construit autour d’elles. Si jamais on ressent le besoin d’ajouter une couche de management, c’est le moment de se demander pourquoi le harness ne fait pas le travail.
3. Customer zero, agentique. L’expression de GitLab “customer zero” pour désigner l’usage de leur propre plateforme sur eux-mêmes est exactement la bonne discipline pour l’outillage IA. Si on n’arrive pas à vibe coder en prod de manière responsable sur notre propre produit, on n’a pas à le vendre comme la réponse pour quiconque d’autre.

À retenir

La lecture ennuyeuse et conventionnelle de l’Act 2 de GitLab, c’est : encore une entreprise tech qui restructure à cause de l’IA. La lecture juste, c’est : la première entreprise cotée a ouvertement misé son operating model sur la thèse empowered-team-meets-agentic-era. Les mouvements structurels - plus plat, plus petit, empowered, recâblé par les agents - sont l’implémentation concrète et réelle la plus aboutie qu’on ait vue de ce à quoi va ressembler la prochaine décennie d’organisations d’ingénierie.

Que GitLab réussisse ou non sur l’exécution, le playbook est désormais public. Il sera emprunté, adapté et réappliqué dans toute l’industrie d’ici deux trimestres. Chaque CPTO qui attendait la preuve que le playbook des empowered teams fonctionne encore à l’ère IA a maintenant la réponse qu’il attendait : oui, et les entreprises cotées s’y sont mises.

Si vous lisez une lettre de CEO ce trimestre, lisez celle-là. Si vous en lisez deux, mettez-la en binôme avec No Rules Rules de Hastings et EMPOWERED de Cagan. L’argument est le même. L’exécution est maintenant publique.

Références

• GitLab Act 2 - Bill Staples - La lettre du CEO aux clients, investisseurs et à l’équipe
• Diriger l’IA est un problème d’empowerment - Le cadrage que cet article valide
• Le Vibe Coding en Prod est un Problème de Management - Le pendant côté contributeur individuel
• EMPOWERED - Marty Cagan (notes de lecture) - Le playbook des empowered teams
• No Rules Rules - Reed Hastings (critique) - High-talent-density, candor, context not control
• Architecture IA à trois niveaux - Quand les agents s’insèrent où
• Le dernier goulot d’étranglement - L’exponentielle et le goulot d’étranglement humain
• Le Skills Framework - La couche de discipline procédurale
• Agentic Development Patterns - Le workflow quotidien
• The Overnight Agent Factory - Le mécanisme de composition