L'IA générative a tenu sa promesse sur un point : elle a considérablement augmenté le débit de production de code des développeurs. C'est un fait, mesurable, que beaucoup d'équipes constatent aujourd'hui. Mais un débit qui augmente à un seul endroit d'une chaîne ne fait pas avancer la chaîne entière plus vite — il déplace simplement le point où elle coince. C'est la théorie des contraintes, formulée par Eliyahu Goldratt il y a près de quarante ans : la vitesse d'un système est toujours dictée par son maillon le plus lent, jamais par la moyenne de ses maillons.
C'est exactement ce que j'observe en ce moment chez nos clients startup SaaS qui ont intégré l'IA dans leur cycle de développement. Les développeurs livrent plus, plus vite. Et deux rôles, jusque-là simplement occupés, sont en train de devenir les points de rupture de l'équipe : les Product Owners et les QA.
Le PO : plus de volume, sans plus de temps
Le symptôme est net : les développeurs, plus rapides, absorbent davantage de user stories par sprint. Mécaniquement, le PO doit en produire plus. Et parce que l'IA permet aux devs d'implémenter des logiques plus complexes en un temps donné, les zones d'ambiguïté qui étaient naturellement compensées par la connaissance des devs sur le produit (ou qui passaient inaperçues) remontent plus vite à la surface : le PO doit donc aussi documenter plus finement, anticiper plus de cas, lever plus d'ambiguïtés en amont.
Le résultat : plus d'US, plus détaillées, dans le même temps qu'avant. Un goulot d'étranglement se forme là où, il y a un an, ce rôle n'était pas identifié comme un point de friction.
Un article récent d'OCTO Technology sur l'apport de l'IA générative au PO propose un cadre utile pour sortir de cette impasse : distinguer :
- le PO accéléré (l'IA comme assistant sur les tâches habituelles : rédaction, tests, documentation)
- du PO augmenté (des capacités nouvelles, auparavant hors de portée : comprendre les règles de gestion réellement implémentées dans le code plutôt que de les redocumenter à la main, prototyper des parcours avant tout engagement de l'équipe de dev).
C'est ce deuxième niveau qui change la donne : il ne s'agit pas de rédiger plus vite la même US, mais de réduire la quantité de rédaction manuelle nécessaire en premier lieu.
La QA : le goulot qu'on ne regarde pas encore assez
Le PO n'est pas seul dans cette situation. Chez ce même client, la QA est en train de vivre un goulot symétrique, et à mon sens sous-discuté : plus de mises en production signifie plus de campagnes de tests de non-régression (TNR) à exécuter. Or, tant que ces TNR restent partiellement manuels, chaque cycle de release supplémentaire vient directement grever une capacité qui, elle, n'a pas augmenté d'un iota.
C'est un cas d'école du même phénomène décrit plus haut, mais appliqué à un rôle qu'on regarde moins souvent dans les analyses sur l'IA et le développement agile : les publications sur le sujet parlent volontiers du développeur et, de plus en plus, du PO; la QA reste le parent pauvre du débat, alors qu'elle subit la même pression, pour les mêmes raisons structurelles.
Les leviers existent pourtant, et ils sont directement transposables du cadre "accéléré / augmenté" évoqué plus haut : génération de scénarios de test à partir du code ou des spécifications, priorisation des TNR par analyse de risque plutôt qu'exécution exhaustive systématique, détection assistée des zones du code les plus susceptibles d'avoir été impactées par un changement. Rien de tout cela n'est de la science-fiction : c'est simplement un chantier qui n'a pas encore reçu la même attention que celui appliqué au code ou aux spécifications.
Un déséquilibre d'adoption, pas un problème de volume
Le vrai diagnostic n'est pas "il y a plus de travail à absorber" : c'est vrai, mais insuffisant.
Le vrai diagnostic est un déséquilibre dans l'adoption de l'IA selon les rôles. Elle a été appliquée massivement à un maillon de la chaîne (le développement) et de façon marginale, voire nulle, aux maillons voisins. Ce déséquilibre, et non le volume en tant que tel, est ce qui produit mécaniquement le goulot.
Deux constats méritent d'être retenus.
- L'IA agit comme un amplificateur des dynamiques existantes. Une équipe déjà mal outillée sur la QA ou la rédaction de specs ne devient pas simplement plus lente sous l'effet de l'accélération du code, elle devient plus chaotique, et plus vite.
- Traiter ce problème rôle par rôle, en accélérant le PO d'un côté et la QA de l'autre indépendamment, revient à optimiser deux maillons isolément sans regarder la chaîne dans son ensemble. Le risque, si l'on ne fait que ça, est de voir le goulot se redéplacer une fois de plus, vers le maillon suivant qu'on n'aura pas anticipé : la mise en production, la revue de code, la sécurité ou ailleurs.
La bonne question à poser à une équipe qui vit cette situation n'est donc pas "comment absorber plus de volume ?" mais "quels maillons de notre chaîne n'ont pas encore reçu leur part d'IA, et pourquoi ?".
Tant qu'un cycle de développement compte un seul maillon accéléré, l'accélération globale reste une illusion : elle ne fait que révéler, un par un, les points où le reste de la chaîne n'a pas suivi.