L'IA bouleverse l'organigramme des équipes logicielles : les chefs de produit écrivent du code

La semaine dernière, Dmitry, product manager chez Zenflow, a conçu, testé et livré en production une nouvelle fonctionnalité — seul, en une journée. Pas de ticket, pas de sprint, pas d'ingénieur impliqué. Quelques jours plus tôt, le designer de l'équipe avait remarqué que l'apparence des plugins IDE s'était écartée du design system. Plutôt que de documenter le problème dans JIRA et d'attendre un slot de développement, il a ouvert un agent IA, corrigé le layout lui-même, itéré en temps réel, et poussé le correctif directement. Ces deux anecdotes ne sont pas des exceptions : elles illustrent un basculement structurel en cours dans les organisations tech. Depuis que l'équipe a adopté une approche "AI-first" en 2025, les cycles de développement sont passés de semaines à jours, puis de jours à heures — les ingénieurs se consacrant désormais à l'architecture et à la validation plutôt qu'à l'écriture de code répétitif.

Ce changement remet en cause une hypothèse fondamentale sur laquelle repose toute organisation logicielle moderne : que l'implémentation est la partie coûteuse. Quand le coût de transformer une intention en logiciel fonctionnel s'effondre, les couches de coordination qui existaient pour protéger le temps des ingénieurs — specs, tickets, handoffs, backlog grooming — deviennent le vrai goulot d'étranglement. L'équipe a réalisé qu'elle optimisait pour une contrainte qui n'existait plus. Pour Dmitry, l'idée d'un mini-jeu à intégrer dans les temps morts de l'interface aurait normalement été éliminée dès la première réunion de priorisation — pas parce que c'était une mauvaise idée, mais parce que le coût d'implémentation la rendait irrationnelle à financer. Quand ce coût tombe à quasi zéro, le calcul change du tout au tout : ce sont exactement les petits détails qui donnent de la personnalité à un produit, et que les utilisateurs retiennent.

Ce phénomène s'inscrit dans une évolution plus large amorcée par le "vibe coding" — l'idée que la création logicielle pouvait s'ouvrir à des non-développeurs. Ce qui relevait de l'aspiration est devenu pratique courante dans certaines équipes pionnières. Les PMs pensent déjà en spécifications, les designers définissent déjà structure et comportement : il ne leur manquait pas la capacité à coder, mais un coût d'implémentation suffisamment bas pour que leur niveau d'abstraction suffise. La question qui se pose désormais pour l'industrie est structurelle : si n'importe quel role métier peut livrer du logiciel directement, comment redéfinir les frontières entre product, design et engineering ? Les entreprises qui répondront le plus vite à cette question auront un avantage de vélocité décisif sur celles qui continuent d'organiser leurs équipes autour d'une contrainte obsolète.