Ce matin j'observais le fonctionnement d'une équipe chez un de mes clients. Et j'ai réalisé que je n'avais jamais vraiment compris la distribution des rôles dans une équipe projet.
Je ne vais pas me faire que des amis, mais je l'admets : j'imaginais grossièrement l'architecte comme le boss, le lead de squad comme le sous-boss, et les devs comme les exécutants. Une hiérarchie classique, verticale, avec le pouvoir en haut et l'exécution en bas.
Mais en fait ce n'est pas du tout ça.
Des périmètres, pas une hiérarchie
Chaque rôle est responsable d'un périmètre différent et complémentaire. Un peu comme des poupées russes : chacune encapsule la suivante avec un niveau d'abstraction supplémentaire.
Le dev est responsable au niveau micro. Il doit livrer du code propre, maintenable et fonctionnel selon les guidelines du projet et les specs données. Mais il n'a pas — et n'a pas à avoir — la vision globale de ce que fait la squad et encore moins les autres squad.
Le lead est responsable de ce que fait sa squad. Il s'assure de la qualité et de la vélocité de ce qui est produit, veille à ce que les guidelines soient respectées, que le présent respecte la vision moyen terme et limite la friction entre squads. Il gère les tâches annexes : fix de problèmes complexes, amélioration de la codebase, déblocages. Mais il ne descend pas au niveau de chaque ligne de code.
L'architecte est responsable de livrer un produit scalable, fiable et maintenable au business. Il n'est pas responsable de chaque feature, mais des guidelines globales et de l'architecture — que je définis comme l'organisation modulaire, efficiente et optimale du code. Il supervise ce que font les squads par le biais des leads, et est responsable de la conception et du dispatch des futures features.
Trois périmètres distincts. Trois niveaux d'abstraction. Chacun fait confiance au niveau en dessous pour son exécution, et rend compte au niveau au-dessus sur son résultat.
Et puis l'IA est arrivée
On pourrait croire que l'IA vient simplement accélérer l'exécution à chaque niveau. Que le dev code plus vite, que le lead review plus vite, que l'archi conçoit plus vite. Mais en fait ce serait passer à côté de quelque chose de plus profond.
Ce que l'IA change, c'est le curseur de responsabilité de chacun. Et elle le change dans les deux sens à la fois.
La pyramide s'étend vers le bas. Le PO devient le premier auteur du code. Sa user story, ses critères d'acceptance — c'est exactement le prompt qui va générer le code. Ce qui était une critique (le PO qui sur-spécifie) devient avec l'IA une réalité littérale. La qualité de la spec devient directement corrélée à la qualité du code produit.
Il y a un CommitStrip de 2016 qui m'a frappé quand j'y ai repensé ce matin. La blague, c'est qu'une spec suffisamment précise et exhaustive est déjà du code. Ce qui était une satire est devenu une description du workflow de 2025.
La pyramide s'étend vers le haut. L'architecte doit monter encore plus haut — vers le produit, le business, les arbitrages stratégiques — parce que les contraintes purement techniques deviennent moins le goulot d'étranglement.
Et entre les deux, tout le monde monte d'un cran :
- Le dev se retrouve à faire ce que faisait le lead : donner des guidelines, relire, arbitrer sur la qualité, avoir une vision plus large que la simple ligne de code.
- Le lead se retrouve à faire ce que faisait l'architecte : penser l'organisation modulaire, anticiper la scalabilité, raisonner sur un périmètre plus grand parce qu'il produit beaucoup plus vite.
- L'architecte monte vers le produit et le business.
- Le PO entre dans le code.
Ce qui est vertigineux
Le plancher monte. Le plafond s'élève. Et tout le monde doit se repositionner sur un niveau d'abstraction supérieur à celui qu'il occupait avant.
Ce que ça change fondamentalement, c'est que l'IA compresse le temps d'exécution. Donc le curseur de responsabilité de chacun glisse vers plus d'abstraction et de jugement. Le risque, c'est que si un dev ne comprend pas vraiment ce qu'il fait valider à l'IA, les erreurs se propagent plus vite et plus loin qu'avant — l'échelle de l'exécution s'emballe sans que le niveau de compréhension suive.
En un sens, l'IA ne supprime pas les niveaux de la pyramide. Elle élève le plancher de ce qu'on attend à chaque étage.
La question qui suit naturellement
Si le PO génère du code relu par le dev, et que le dev raisonne comme un lead, est-ce qu'on a encore besoin de la même densité de chaque profil ? Est-ce que les équipes deviennent plus petites, ou est-ce qu'elles deviennent composées de gens plus polyvalents — capables de naviguer sur plusieurs niveaux d'abstraction ?
C'est la question que j'explore dans les prochains articles. Et je pense que la réponse n'est pas celle qu'on croit.
Cet article est le premier d'une série sur l'impact de l'IA dans les équipes tech. La suite : le problème du junior, le vrai goulot d'étranglement, et le nouveau profil stratégique.