Seeing AGI (8) : la renaissance du rôle humain
J'ai récemment participé à Delight Spark à San Francisco, et une conversation m'est restée en tête bien après la fin de l'événement. Elle portait sur les organisations à l'ère de l'IA.
Dans mes sept précédents articles de la série Seeing AGI, j'ai abordé l'arrivée de l'AGI, le vibe working et les systèmes multi-agents. Mais la question à laquelle je reviens sans cesse est plus simple : qu'arrive-t-il au rôle humain au sein de l'entreprise ? Avant que l'IA ne réécrive l'organigramme, elle réécrit la personne.
Trop d'entreprises voient encore l'IA comme une mise à jour logicielle pour les mêmes personnes occupant les mêmes postes. C'est une erreur de cadrage. L'IA n'accélère pas seulement le travail. Elle change qui fait quoi, qui détient le contexte, et comment circule le jugement.
Chaque vague technologique transforme le rôle humain
Quand les gens découvrent une technologie de rupture, ils supposent généralement que leur métier restera identique, juste plus rapide. L'histoire montre que c'est une illusion.
La première chose qui change est rarement l'organigramme sur le papier. La première chose qui change, c'est ce que les humains font toute la journée, de qui ils dépendent, à qui ils rendent compte, et quel type de jugement le système récompense réellement.
Donc, si nous voulons comprendre clairement l'IA, nous ne devrions pas seulement nous demander ce que les modèles peuvent faire. Nous devrions nous demander ce que les vagues technologiques précédentes ont fait au travail lui-même.
L'électricité n'a pas seulement modernisé l'usine. Elle a transformé les gens à l'intérieur.
La fameuse leçon de l'électrification n'est pas seulement que l'électricité était puissante. C'est que la première vague d'adoption a déçu, parce que les usines ont conservé leur ancienne disposition. Les propriétaires ont remplacé les machines à vapeur par des dynamos, mais ont gardé la même logique d'énergie centralisée, les mêmes arbres de transmission, les mêmes courroies, et la même géométrie de production.
Le vrai bond est arrivé plus tard, quand les usines ont adopté l'entraînement individuel — des moteurs électriques propres à chaque machine. À ce moment-là, le bâtiment lui-même pouvait changer. Les ateliers de plain-pied sont devenus plus simples à concevoir. Les machines n'avaient plus à être organisées autour d'une seule colonne mécanique. Le flux de travail pouvait être repensé autour de la vitesse, de la sécurité et de la spécialisation.
Et une fois l'usine transformée, les rôles humains ont changé avec elle. L'ancienne logique des salles des machines centrales, des plans organisés autour d'arbres de transmission, et de la maintenance bâtie autour d'une seule source d'énergie a commencé à s'estomper. À sa place est apparu un nouveau besoin : électriciens, ingénieurs électriciens, planificateurs d'usine, et un nouveau type de gestion des opérations. Paul David a écrit que l'électrification à grande échelle exigeait de constituer « un corps d'architectes industriels et d'ingénieurs électriciens expérimentés ». C'est exactement le sujet. Une nouvelle source d'énergie n'a pas simplement rendu les anciens ouvriers plus rapides. Elle a créé de nouveaux spécialistes, de nouvelles relations hiérarchiques, et une nouvelle logique opérationnelle.
Les ordinateurs n'ont pas seulement automatisé les bureaux. Ils ont créé des rôles informationnels entièrement nouveaux.
L'ère informatique a fait quelque chose de similaire. Avant l'informatisation, les grandes organisations s'appuyaient sur des couches de commis, de dactylos, de personnel de classement, de comptables et d'opérateurs de machines pour faire circuler l'information à la main. Puis sont arrivés les services de traitement de données, les opératrices de perforation, les programmeurs, les analystes systèmes, et plus tard les administrateurs de base de données et les responsables IT.
Certains rôles ont diminué. D'autres ont surgi de nulle part. Les opératrices de perforation sont devenues une profession reconnaissable à l'ère des cartes perforées, puis ont progressivement disparu avec la diffusion de l'informatique directe. Dans le même temps, l'analyste systèmes est apparu comme un nouveau rôle de pont — quelqu'un capable de comprendre l'activité, de concevoir le système, de préparer des schémas pour les programmeurs, et de traduire les besoins de la direction en structure technique. Ce rôle n'a de sens que dans un monde où le logiciel devient une partie de la façon dont l'entreprise pense.
Cela a aussi modifié les lignes hiérarchiques. Une fois que les systèmes d'information sont devenus centraux dans les opérations, les entreprises ont bâti des organisations MIS et IT, des couches de gestion de projet, des équipes systèmes, puis des fonctions logicielles d'entreprise. L'autorité a de plus en plus circulé à travers l'architecture de l'information, pas seulement les opérations physiques.
Le logiciel a créé l'organisation produit moderne.
Puis l'ère du logiciel a ajouté une nouvelle couche. À mesure que la complexité logicielle explosait, l'organisation s'est à nouveau divisée. Le product management a émergé pour combler un vide entre le métier, les utilisateurs et l'ingénierie. Dans le logiciel, il ne suffisait pas de commercialiser un produit. Quelqu'un devait décider quoi construire, traduire les scénarios utilisateurs et rester proche de l'ingénierie tout au long du cycle.
L'UX et le design d'interaction ont mûri à mesure que l'informatique personnelle, puis le web, rendaient l'utilisabilité économiquement incontournable. La QA est devenue une fonction distincte parce que le test ne pouvait plus rester dans la tête du programmeur. Plus tard, Agile et DevOps ont commencé à brouiller à nouveau ces lignes, en intégrant les testeurs plus tôt dans le cycle et en faisant de la qualité une responsabilité partagée.
La structure PM, Designer, Developer et Tester n'a donc pas été dictée par la nature. Elle appartenait à l'ère précédente du génie logiciel. C'était une réponse rationnelle aux limites de la communication humaine, à la fragmentation des connaissances, au codage manuel et à des boucles de feedback plus lentes.
L'ancienne chaîne de montage a été pensée pour un autre monde
Une fois cette histoire vue clairement, l'organigramme logiciel actuel paraît bien moins permanent que la plupart des gens ne le pensent. Ce n'est que la dernière couche d'une longue séquence de réorganisations technologiques.
Dans l'ancien monde du logiciel, un projet avait besoin d'un empilement de fonctions spécialisées avant de pouvoir avancer d'un pouce. La logique hiérarchique reflétait généralement le flux de travail lui-même : le produit produisait les exigences, le design les traduisait, l'ingénierie les implémentait, la QA les validait, et le management coordonnait les passages de relais entre ces silos.
Pensez à ce que faisait un PM autrefois : il passait des semaines à rédiger d'énormes documents de spécifications de 20 pages à balancer par-dessus le mur. Le Designer passait ensuite des semaines à pousser manuellement des pixels pour traduire ces specs en maquettes. Le Developer prenait ces maquettes et passait des mois à taper du code boilerplate. Enfin, le Tester passait des semaines à traquer les incohérences et les bugs.
Cette structure avait du sens quand chaque étape devait être réalisée par un spécialiste différent utilisant des outils différents, avec des transitions coûteuses entre eux. Les passages de relais n'étaient pas que de la bureaucratie. C'était la façon dont le système se protégeait de la complexité.
Mais quand un agent IA peut aider à générer le code, ébaucher l'UI, créer des cas de test, et compresser l'itération à quelques minutes, la même structure commence à jouer contre elle-même. Le passage de relais cesse d'être un mécanisme de sécurité pour devenir un pur frein.
La plupart des « transformations IA » d'aujourd'hui restent piégées ici. Les entreprises donnent un outil d'écriture IA au PM, un outil de design IA au Designer, et un outil de codage IA au Developer, mais conservent les mêmes lignes hiérarchiques et la même division du travail. C'est connecter une nouvelle source d'énergie à une vieille machine.
C'est pourquoi je crois que le début de cette histoire compte tellement. L'IA n'est pas la première technologie à réorganiser le travail. Mais c'est peut-être la première à le faire à cette vitesse, tout en faisant converger autant de rôles de connaissance dans le même moment d'exécution.
Ce que je vois à l'intérieur de Genspark
Chez Genspark, je vois déjà la prochaine couche de cette histoire s'écrire en temps réel. Nous sommes désormais une organisation d'environ 70 personnes. Notre structure est impitoyablement plate.
Nous ne dotons pas les projets de départements massifs et multidisciplinaires. La grande majorité de nos projets sont menés par des pods agiles de seulement 1 à 3 personnes. Comme le flux de travail est compressé, les gens opèrent au plus près de toute la chaîne de création de valeur.
Cela commence dès le premier jour. Les nouveaux employés ne sont pas cachés dans des rôles étroits ni forcés de lire de la documentation pendant un mois. Ils sont propulsés sur la ligne de front immédiatement. Nous voyons régulièrement des gens livrer des fonctionnalités complexes et réelles dès leur première semaine. Même des membres de l'équipe qui n'avaient jamais écrit une seule ligne de code de leur vie avant de nous rejoindre lancent des fonctionnalités.
À l'ère précédente, cela aurait paru imprudent ou impossible. Dans cette ère, c'est la norme. Les personnes ambitieuses s'épanouissent ici parce qu'elles ne sont plus enfermées dans une seule case.
Comment les rôles changent vraiment
Quand le flux de travail se compresse à ce point, les rôles professionnels ne disparaissent pas. Ils mutent. Ils s'élèvent.
Le PM : du rédacteur de specs au chef d'orchestre du système
Le PM ne passe plus des semaines à rédiger des documents statiques pour qu'un autre les interprète. Il utilise l'IA pour générer immédiatement des prototypes vivants. Il pilote le système, teste la logique en temps réel, et porte le résultat final plutôt que de simplement porter les exigences.
Le Designer : du traducteur front-end au juge ultime
Notre récente sortie de Genspark Design en est l'exemple parfait. Dans l'ancien processus, le Designer était un traducteur en amont. Il devait dessiner manuellement les écrans avant que quiconque puisse construire. Aujourd'hui, le chemin d'une idée abstraite à un design complet, puis à un produit lancé, est continu.
Comme l'IA peut générer en quelques secondes des dizaines de prototypes fonctionnels en haute fidélité, le rôle du Designer se déplace en aval du pipeline. Il devient le juge. Il fixe le niveau de qualité. Il protège le niveau de goût. Il valide l'expérience. Il décide laquelle des itérations de l'IA possède la juste âme pour la marque.
Le Developer : du tapeur de code à l'architecte système
La première semaine d'un développeur n'est plus consacrée à configurer son environnement local et à lire de vieilles bases de code. Elle est consacrée à livrer. Il passe moins de temps à taper du boilerplate et plus de temps à architecturer la logique, à guider les agents et à résoudre les problèmes structurels profonds que l'IA ne sait pas encore voir.
Le Tester : du gardien manuel à l'ingénieur d'infrastructure d'agents
Dans le flux AI-native, chacun devient le testeur de sa propre fonctionnalité. La personne qui construit la fonctionnalité génère aussi les cas de test, vérifie les conditions limites, valide l'expérience, et décide si c'est prêt à être livré. Le test ne se trouve plus en bout de chaîne comme une porte séparée. Il devient partie intégrante de l'écriture elle-même.
Cela ne veut pas dire que le testeur traditionnel disparaît. Le rôle monte d'un cran. Il devient un rôle d'infrastructure. Au lieu de vérifier manuellement chaque écran après coup, cette personne aide à s'assurer qu'une fois les fonctionnalités livrées par l'équipe, le système reste stable, observable et fiable en production.
En ce sens, le nouveau testeur ressemble davantage à un ingénieur d'infrastructure pour la qualité. Il bâtit les frameworks, les garde-fous, le monitoring, les boucles d'évaluation et la logique de release qui rendent toute l'organisation plus fiable. Il aide aussi à créer une infrastructure plus accueillante pour les agents, afin que l'IA puisse participer plus efficacement aux tests, au debug et à l'amélioration continue.
Dans toutes les disciplines, la tendance est exactement la même : le jugement devient bien plus important que le passage de relais. La détention du contexte devient plus précieuse que la spécialisation étroite.
Le CEO : de Chief Executive Officer à Chief Context Officer
Une fois qu'on voit à quel point l'IA recombine en profondeur les rôles, on ne peut pas s'arrêter aux PM, Designers, Developers et Testers. Le CEO est lui aussi en train d'être réécrit.
Dans l'ancien modèle d'entreprise, l'échelle éloignait le CEO du travail. L'organisation devenait trop spécialisée, trop stratifiée, trop lente. Le travail du CEO devenait de gérer la complexité à travers d'autres personnes.
Cette distance n'était pas un trait de personnalité. Elle était structurelle. Dans beaucoup d'entreprises, le CEO ne pouvait plus toucher directement au produit parce que le travail avait été fragmenté à travers trop de fonctions, de réunions et de passages de relais.
L'IA brise ce modèle. Un CEO prêt à apprendre peut revenir dans le travail. Il peut explorer des idées produit, examiner des prototypes, tester des flux, remettre en question des hypothèses, et même contribuer à l'exécution avec l'IA. Pas parce que le CEO devrait redevenir un micro-manager, mais parce que le mur entre le leadership et la création s'amincit.
Le métier change donc. Le CEO de l'ère IA commence à ressembler moins à un Chief Executive Officer et plus à un Chief Context Officer. Son rôle est de fixer la direction, de clarifier le jugement, de rapprocher les droits de décision du terrain, et de concevoir les interfaces qui permettent aux petits pods d'avancer avec une vraie autonomie.
Dans l'ancien modèle, le pouvoir venait de la distance et du contrôle. Dans le nouveau, le pouvoir vient du contexte, du goût, de la clarté, et de la capacité à aider l'organisation à penser et à bouger comme un seul système. Et une fois que le CEO change, l'organisation ne peut pas rester la même. La réécriture des rôles devient naturellement la réécriture de l'organisation.
La nouvelle organisation n'est pas seulement plus plate. Elle est structurellement différente.
Je ne pense pas que la bonne description de cette nouvelle entreprise soit simplement « plate ». Plate signifie seulement moins de couches. Ce que nous voyons est un changement plus profond. L'unité de base de l'organisation n'est plus la fonction. C'est le pod.
Dans l'ancienne structure, l'entreprise était bâtie autour de départements. Le produit siégeait à un endroit. Le design à un autre. L'ingénierie quelque part encore. La QA à la fin. L'organigramme reflétait la chaîne de relais.
Dans la nouvelle structure, l'entreprise commence à ressembler à un réseau de petits pods à fort contexte. Un pod de 1 à 3 personnes travaille au plus près du problème, au plus près de l'utilisateur et au plus près de l'IA. Il porte une plus grande part de la chaîne, de l'idée à la livraison. Il porte plus de contexte. Il prend plus de décisions. Il attend moins.
Dans une entreprise de plusieurs milliers de personnes, cela ne peut pas vouloir dire qu'un seul CEO touche directement des centaines de pods. Ce n'est pas scalable. La version scalable est un réseau de réseaux : des pods regroupés en clusters de mission, tenus ensemble par un contexte partagé, un goût partagé, une clarté partagée et un design système partagé. Des couches de leadership existent toujours, mais leur travail change. Elles ne sont plus des goulots d'approbation. Elles deviennent des routeurs de contexte, des concepteurs d'interfaces, et des multiplicateurs de force. Dans ce modèle, le CEO ne gère pas chaque pod. Le CEO conçoit l'architecture qui permet à de nombreux pods d'avancer avec cohérence sans reconstruire l'ancienne bureaucratie. Voilà à quoi ressemble l'échelle AI-native : non pas une pyramide plus plate, mais un autre système.
Une fois que cela arrive, la hiérarchie cesse d'être le principal mécanisme de coordination. Le contexte devient le principal mécanisme de coordination. La question la plus importante n'est plus « Qui rend compte à qui ? ». Elle devient « Qui détient vraiment le contexte, et qui a le jugement pour agir dessus ? ».
Cela change aussi la raison d'être des couches de leadership. Dans l'ancien monde, une grande partie du middle management existait pour traduire, résumer, coordonner et faire circuler l'information à travers les frontières fonctionnelles. Dans le nouveau monde, ces rôles ne restent précieux que s'ils évoluent vers des bâtisseurs de systèmes, des relecteurs de qualité, des coachs de talents et des intégrateurs entre pods. Le manager-courroie de transmission perdra régulièrement de l'importance.
En une phrase, l'organisation AI-native, c'est ceci : un réseau de petits pods à forte appropriation du contexte, soutenus par des agents IA, alignés par un jugement partagé, et reliés par des interfaces légères plutôt que par une hiérarchie lourde.
La fenêtre pour réécrire l'entreprise
Si la réécriture des rôles mène à la réécriture du CEO, et la réécriture du CEO à la réécriture de l'organisation, alors il ne s'agit pas d'une mise à niveau d'outils. Il s'agit d'une réécriture d'entreprise. Arrêtez donc de fixer uniquement votre stack IA. Regardez vos gens. Regardez votre structure.
Posez-vous les questions difficiles. Vos gens sont-ils encore piégés dans des rôles étroits de traduction ? Vos meilleurs cerveaux préparent-ils encore des passages de relais au lieu de poser des jugements ? Votre organigramme est-il encore bâti pour l'ancienne chaîne PM-Designer-Developer-Tester ? Les droits de décision sont-ils encore trop loin des personnes qui détiennent le vrai contexte ?
Acheter un accès à l'IA est facile. La vraie transformation est plus difficile. Elle implique de redessiner les rôles, de pousser l'autonomie dans les petits pods, de rebâtir l'infrastructure autour des agents, et de redéfinir le leadership lui-même.
Les gagnants de cette ère ne se contenteront pas d'utiliser de meilleurs modèles. Ils reconstruiront plus vite. Ils remplaceront les chaînes de relais par des réseaux de pods. Ils déplaceront le contexte vers le terrain. Ils relèveront la barre du jugement.
L'IA ne réécrit pas seulement les tâches. Elle réécrit l'entreprise. La fenêtre est ouverte maintenant. Elle ne le restera pas longtemps.