Dans les deux premiers articles de cette série, j'explorais comment l'IA redistribue les rôles dans une équipe tech et ce qu'elle fait au pipeline de formation des juniors. Mais il y a une question plus immédiate, plus concrète, que beaucoup d'équipes affrontent dès maintenant : est-ce que l'IA permet vraiment de faire la même chose avec moins de gens ?
La réponse courte : non. Et j'en fais l'expérience directement.
Le fantasme de la réduction d'effectifs
L'argument est séduisant. L'IA génère du code beaucoup plus vite, donc on a besoin de moins de personnes pour produire la même quantité. On réduit les équipes, on garde les meilleurs, on optimise les coûts.
C'est le calcul le plus immédiat, et c'est celui que beaucoup d'entreprises sont en train de faire. Mais ce calcul oublie quelque chose d'essentiel : l'IA fournit des bras supplémentaires, mais pas de la compréhension.
Le vrai goulot d'étranglement dans un projet logiciel n'a en fait jamais été la capacité à produire des lignes de code. C'est la capacité à comprendre ce que le code fait, pourquoi il le fait, et ce qui va se passer si on le modifie.
L'IA ne change pas ça. Elle l'exacerbe.
Ce que le vibe coding sans ownership coûte vraiment
J'ai une expérience directe de ce problème avec Haark, le CRM que je développe. Le projet a été vibecodé au départ — je n'ai pas développé la base moi-même. Résultat : j'ai une connaissance partielle de la codebase, une architecture que je n'ai pas conçue, et des décisions techniques que je n'ai pas prises.
Au démarrage, ça semblait un avantage. On avait un produit fonctionnel rapidement. Mais très vite, j'ai compris le vrai coût.
J'ai passé mon temps à faire le pompier. Un bug ici, une regression là, un comportement inattendu ailleurs. Je réagissais en permanence, sans jamais avoir le temps de vraiment comprendre ce que je maintenais. Et parce que je ne comprenais pas l'architecture dans sa globalité, chaque intervention était risquée — je ne pouvais pas prédire les effets de bord d'un changement.
Aujourd'hui on s'en sort à peu près parce qu'il n'y a encore qu'un seul client. Mais je sais que ce n'est pas viable à long terme. Chaque nouvelle feature potentielle me demande un effort de compréhension disproportionné. Et je suis positionné en réaction permanente, pas en proaction.
Ce n'est pas un problème de vélocité. C'est un problème de compréhension.
La dette de compréhension
On parle beaucoup de dette technique — du code mal écrit, des raccourcis pris sous pression, des abstractions bancales qu'il faudra réécrire un jour. C'est un concept connu, documenté, géré.
Mais il y a une autre forme de dette dont on parle moins : la dette de compréhension. Elle ne se voit pas dans le code. Elle se voit dans la tête de celui qui doit le maintenir.
Un projet vibecodé sans ownership accumule cette dette à une vitesse terrifiante. Le code tourne. Les features arrivent. Mais personne ne peut vraiment prédire l'impact d'un changement. Personne ne sait vraiment où est la logique métier critique. Personne ne comprend pourquoi certaines décisions ont été prises.
Et le paradoxe, c'est que l'IA qui vous a mis dans cette situation ne peut pas vraiment vous en sortir. Parce qu'elle aussi a besoin de ce contexte que vous n'avez pas encore.
Petites équipes ou gens polyvalents ?
Face à ça, il y a deux tentations.
La première : réduire les effectifs. Même output, moins de personnes, coûts optimisés. C'est la logique de productivité immédiate.
La seconde : miser sur des gens plus polyvalents. Même nombre de personnes, mais chacun couvre un spectre plus large — un dev qui comprend le produit, un PO qui comprend les contraintes techniques, un lead qui parle au business.
Ces deux options ne s'excluent pas, mais elles ont des implications très différentes.
Le risque de la première, c'est de se retrouver avec des équipes trop petites pour gérer la complexité générée par l'IA elle-même. Parce que produire plus vite, ça veut aussi dire accumuler de la dette technique plus vite, faire des erreurs à plus grande échelle, et avoir besoin de gens capables de comprendre et corriger ce que la machine a produit.
Sur un projet avec du legacy, ou avec une codebase qu'on n'a pas entièrement construite soi-même, je pense qu'il vaut mieux avoir des gens polyvalents qui vont monter en compétence que des équipes squelettiques qui naviguent à vue.
La réduction d'effectifs est un fantasme inatteignable sans une bonne maîtrise de la codebase. Et cette maîtrise prend du temps — du temps qu'on ne peut pas compresser avec de l'IA.
Comment solder la dette de compréhension
Ma stratégie sur Haark, c'est de procéder en deux temps.
D'abord, créer un maximum de tests automatisés. Pas pour couvrir tous les cas, mais pour avoir un filet de sécurité avant de toucher à l'architecture. Des tests qui me permettent de savoir si un changement casse quelque chose d'existant.
Ensuite, refonte de l'architecture. Rendre le code plus intelligible, régler les problèmes de duplication, réorganiser les modules de façon à ce que l'intention soit lisible. Ce n'est pas la stratégie idéale — c'est un gros refactoring qui peut introduire des bugs. Mais je pense que c'est indispensable avant que la codebase ne grossisse davantage.
C'est un investissement douloureux à court terme. Mais c'est le seul moyen de passer du mode réactif au mode proactif. Et c'est la condition pour que l'IA devienne un vrai levier plutôt qu'un accélérateur de chaos.
Ce que ça dit sur l'IA comme outil
L'IA est un excellent amplificateur. Mais elle amplifie dans les deux sens.
Si vous comprenez votre codebase, elle vous rend beaucoup plus efficace. Si vous ne la comprenez pas, elle vous aide à produire plus vite des choses que vous comprenez encore moins.
C'est pour ça que la maîtrise de la codebase est le vrai capital d'une équipe à l'ère de l'IA. Pas la vélocité. Pas le nombre de features livrées. La capacité à comprendre ce qu'on maintient, à anticiper les effets de bord, à prendre des décisions techniques informées.
Sans ça, l'IA ne réduit pas la complexité. Elle la cache — jusqu'à ce qu'elle explose.
Dans le prochain article : le profil qui émerge de tout ça — le généraliste AI-driven, pourquoi il devient stratégique, et comment il se distingue du simple "touche-à-tout".
Cet article fait partie d'une série sur l'impact de l'IA dans les équipes tech.