Dans les trois premiers articles de cette série, j'ai exploré comment l'IA redistribue les rôles, menace le pipeline de formation des juniors, et exacerbe le problème de la compréhension de codebase. Tout ça converge vers une question : quel est le profil qui s'en sort le mieux dans ce nouveau contexte ?
Ce n'est pas le super-dev qui code vite. Ce n'est pas non plus le manager qui "comprend l'IA sans la pratiquer". C'est quelque chose de plus rare et de plus difficile à former : le généraliste AI-driven.
Ce que l'histoire du software nous apprend
L'IA n'est pas la première technologie à comprimer la pyramide des rôles. Les frameworks ont rendu les DBA moins indispensables au quotidien. Le cloud a absorbé une partie des ops. À chaque fois, le rôle n'a pas disparu — il s'est raréfié et spécialisé. On en a besoin de moins, mais ceux qui restent doivent être meilleurs.
Ce qui est différent cette fois, c'est l'amplitude du changement. L'IA ne comprime pas un seul niveau — elle fait monter toute la pyramide en même temps. Et elle le fait dans les deux sens : vers le bas avec le PO qui entre dans le code, vers le haut avec l'architecte qui monte vers le business.
Dans ce contexte, deux types de profils émergent comme stratégiques.
Le spécialiste qui reste indispensable
Le spécialiste ne disparaît pas. Mais son rôle change.
Là où il intervenait au quotidien pour des problèmes récurrents, il devient consultatif. On fait appel à lui quand le généraliste a atteint ses limites de compréhension — sur un problème de performance critique, sur une décision d'architecture complexe, sur une faille de sécurité qui demande une expertise pointue.
Son périmètre se réduit en fréquence, mais s'approfondit en valeur. Il n'est plus dans le flux de production quotidien. Il est la référence qu'on appelle quand ça compte vraiment.
Le généraliste AI-driven — pas un dilettante
Le généraliste AI-driven est le profil qui monte. Mais attention à ne pas confondre avec le touche-à-tout superficiel qui "fait un peu de tout sans vraiment maîtriser quoi que ce soit".
Ce qui le définit, c'est la capacité à naviguer entre les niveaux d'abstraction. Comprendre un problème métier, le traduire en architecture, l'implémenter, le tester, et expliquer le tout à un non-technique. Ce profil existe — c'est souvent le CTO d'une startup early stage — mais il a toujours été difficile à former et difficile à scaler.
Ce que l'IA change, c'est qu'elle lui donne les bras pour exécuter sur plusieurs niveaux sans avoir besoin d'une équipe entière derrière lui. Elle prend en charge l'exécution, libère de la bande passante cognitive, et lui permet de se concentrer sur ce qu'il fait vraiment bien : comprendre, arbitrer, décider.
Sa valeur, ce n'est pas ce qu'il produit. C'est ce qu'il comprend.
La question de la bande passante cognitive
Est-ce que l'IA, en prenant en charge l'exécution, libère suffisamment de bande passante cognitive pour que des gens "normalement spécialisés" puissent s'élever vers plus de généralisme ?
Je pense que oui — mais à une condition. Il faut avoir construit des fondations solides avant de déléguer l'exécution. Quelqu'un qui n'a jamais vraiment codé ne devient pas un généraliste AI-driven parce qu'il sait utiliser Cursor. Il devient un utilisateur avancé d'un outil qu'il ne comprend pas vraiment.
Le généraliste AI-driven, c'est quelqu'un qui a d'abord été bon dans au moins un domaine — dev, produit, architecture — et qui utilise l'IA pour étendre son spectre. Pas quelqu'un qui utilise l'IA pour éviter d'avoir à être bon dans quoi que ce soit.
C'est une nuance importante. Et c'est probablement ce qui rend ce profil difficile à former en masse.
Ce que ça change dans une DSI
Dans une organisation tech classique, la valeur était distribuée verticalement. Les seniors d'un domaine transmettaient leur expertise aux juniors du même domaine. Les équipes étaient organisées par spécialité.
Dans une DSI AI-driven, la valeur se redistribue horizontalement. Ce qui devient rare — et donc précieux — c'est la capacité à faire le lien entre les domaines. Entre le métier et la technique. Entre le court terme et le long terme. Entre ce que l'IA peut faire et ce qu'elle ne doit pas faire.
Le généraliste AI-driven est l'élément stratégique de cette organisation. Pas parce qu'il remplace les spécialistes, mais parce qu'il permet à l'organisation de fonctionner avec moins de friction entre les niveaux d'abstraction.
Ce que ça demande concrètement
Former ce profil — ou le devenir soi-même — demande quelque chose que la plupart des formations techniques n'enseignent pas : l'habitude de raisonner sur plusieurs niveaux en même temps.
Concrètement, ça passe par quelques pratiques que j'essaie de cultiver :
Se forcer à expliquer les décisions techniques à des non-techniques. Pas pour vulgariser, mais pour vérifier qu'on comprend vraiment ce qu'on fait. Si on ne peut pas l'expliquer clairement, c'est qu'on ne le comprend pas vraiment.
Documenter les décisions d'architecture — pas seulement le quoi, mais le pourquoi et les alternatives qu'on a écartées. Les ADRs (Architecture Decision Records) sont un bon format pour ça. Ça force à articuler le raisonnement, et ça crée une mémoire externe qui compense l'absence de senior à côté.
Utiliser l'IA comme interlocuteur, pas comme exécutant. Lui poser des questions sur les tradeoffs, lui demander ce qui pourrait mal tourner dans six mois, lui faire challenger ses propres décisions. C'est très différent de lui demander de générer du code.
La conclusion de la série
Quatre articles plus tard, voilà où j'en suis.
L'IA ne supprime pas les niveaux de la pyramide. Elle les réorganise. Elle élève le plancher de ce qu'on attend à chaque étage, et elle crée de la valeur là où la compréhension — pas la production — est au centre.
Le vrai risque n'est pas que l'IA remplace les développeurs. C'est qu'elle crée une génération de gens capables de produire du code sans le comprendre, de maintenir des systèmes sans en maîtriser les fondations, et de prendre des décisions techniques sans en assumer les conséquences.
Se prémunir contre ça, c'est le vrai enjeu pour les équipes tech dans les prochaines années. Et ça commence par une chose simple : ne pas confondre vélocité et maîtrise.
L'IA vous donne la vélocité. La maîtrise, vous devez encore la construire vous-même.
Cet article conclut la série sur l'impact de l'IA dans les équipes tech. Les prochains articles exploreront des sujets connexes : la review de code à l'ère de l'IA, comment solder la dette de compréhension d'un projet vibecoded, et comment acquérir seul le recul d'un senior.