Pourquoi le temps passé et les ETP sont des indicateurs obsolètes

Un modèle de mesure hérité d'une ère révolue

Le modèle historique de facturation IT repose sur une équation simple : plus un projet est complexe, plus il faut de jours-homme, donc plus il coûte cher. Ce modèle avait du sens quand le goulot d'étranglement était la production manuelle de code. Chaque ligne nécessitait un développeur, chaque fonctionnalité exigeait des heures d'écriture, de débogage et de tests manuels. Le temps passé était un proxy raisonnable de la valeur produite.

Ce n'est plus le cas.

Avec l'IA générative bien orchestrée, le volume de code produit n'est plus corrélé à l'effort humain. Un ingénieur augmenté par des agents IA peut générer en quelques heures ce qui prenait des semaines à une équipe de huit personnes. Mesurer la valeur au temps passé revient alors à pénaliser l'efficacité : plus on est rapide, moins on facture. C'est absurde.

Le volume de code est un indicateur encore pire. Dans une approche traditionnelle, 80 % de l'effort allait à l'exécution (le code) et 20 % à la planification et la revue. Le résultat : de la dette technique, du retravail, des erreurs tardives. La Software Factory 10x inverse cette proportion — 40 % de Context Engineering, 20 % de code, 40 % de revue. On produit moins de code, mais du code juste du premier coup. Mesurer les lignes produites, c'est mesurer le bruit, pas le signal.

Le Context Engineering comme nouvel actif stratégique

Ce qui crée la valeur désormais, ce n'est plus le code lui-même mais le contexte fourni à l'IA : les spécifications structurées, les règles métier codifiées, l'architecture documentée, les conventions explicitées. Ce contexte est versionné dans Git, testé et évalué comme n'importe quelle dépendance logicielle. Chaque cycle enrichit les suivants — c'est le principe du Compound Engineering.

La différence fondamentale : dans l'ingénierie traditionnelle, chaque fonctionnalité ajoutée augmente la complexité du système. Dans le Compound Engineering, la complexité décroît à chaque itération parce que le contexte accumulé rend chaque décision suivante plus rapide et plus précise. L'infrastructure contextuelle représente aujourd'hui 24,2 % de la documentation totale d'un projet bien structuré — un investissement qui se rentabilise par une vélocité multipliée par cinq.

Un projet estimé à 500 000 € en jours-homme traditionnels peut être livré pour environ 100 000 € avec une qualité supérieure. Le client n'a pas payé moins de « travail » — il a payé pour un résultat, rendu possible par un investissement massif en amont sur le contexte plutôt que sur la production brute de code.

La Sandwich Team rend le modèle ETP caduc

L'ancienne « Pizza Team » de huit personnes, découpée en spécialités (front, back, ops, QA, design), avec une complexité de coordination en N², est remplacée par la Sandwich Team : une à deux personnes augmentées qui produisent 80 % du livrable avec zéro délai de coordination interne. L'App Owner, assisté par l'IA, maîtrise toute la chaîne — UX, Front, API, Back, Sécurité.

Compter des ETP dans ce modèle n'a plus de sens. Trois ingénieurs SFEIR augmentés ont l'impact de douze ingénieurs traditionnels. Le client qui achète « 3 ETP » sous-estime massivement ce qu'il reçoit. Celui qui achète « 12 ETP » surpaye massivement ce dont il a besoin.

Ce n'est pas une question de compression des effectifs. C'est une question de découplage entre le nombre de personnes et la capacité de production. L'IA ne remplace pas les ingénieurs — elle démultiplie chacun d'entre eux. Les contributeurs occasionnels (les 20 % restants) interviennent ponctuellement via un contexte partagé, sans les frictions de l'onboarding traditionnel.

Les métriques qui comptent vraiment

Si le temps et les ETP sont obsolètes, que mesurer ? Le rapport DORA 2025 propose un cadre actualisé avec une métrique révélatrice : le Rework Rate — le taux de retravail. C'est le coût caché de la vélocité artificielle : les équipes qui produisent vite grâce à l'IA mais sans fondations solides passent plus de temps à corriger qu'à innover.

Les indicateurs pertinents pour l'ère de l'IA industrielle sont :

• Résultats livrés : fonctionnalités en production, périmètre couvert, valeur métier démontrée
• Qualité dès la première passe : taux de retravail, change failure rate, couverture de tests
• Capitalisation du contexte : croissance et fraîcheur de l'infrastructure contextuelle, temps de maintenance hebdomadaire
• Vélocité composée : chaque itération est-elle plus rapide que la précédente ? C'est le signe que le Compound Engineering fonctionne
• Time-to-production : le temps entre l'intention et le déploiement en production, pas le temps de codage

Le bon modèle : l'engagement de résultats

La seule unité de mesure pertinente devient le résultat livré : une application en production, un périmètre fonctionnel couvert, une valeur métier démontrée. L'engagement ne porte plus sur un volume de jours mais sur un livrable défini, avec un niveau de qualité mesurable.

C'est pourquoi la démarche progressive — projet preuve à moins de 40 000 €, puis montée en puissance, puis projets stratégiques — construit la confiance sur des résultats constatés, pas sur des feuilles de temps. Le client voit ce qu'il obtient avant de s'engager davantage.

Pour les DSI et les directions achats, cela implique un changement de posture : ne plus demander « combien de personnes ? » mais « quel résultat, à quelle échéance, avec quelle garantie de qualité ? ». Les ESN qui continuent de vendre du temps dans un monde où l'IA rend le temps non corrélé à la valeur se condamnent à une course vers le bas. Celles qui vendent des résultats, adossés à une méthodologie industrielle comme la Software Factory 10x, créent un cercle vertueux de confiance et de performance.

Le temps passé et les ETP ne sont pas de mauvais indicateurs. Ce sont des indicateurs d'une ère révolue. L'avenir appartient à ceux qui mesurent ce qui compte : la valeur livrée.