Depuis les débuts de l'ingénierie logicielle, notre industrie s'est construite autour d'une unité de mesure fondamentale, presque sacrée : le temps humain. Que l'on parle en "jours-homme", en "Story Points" ou en "T-Shirt sizes", la métrique sous-jacente est toujours restée la même. Nous estimions la charge cognitive et le temps de frappe d'un individu face à son clavier.
Aujourd'hui, l'intégration massive des assistants génératifs (LLMs) dans nos IDE bouleverse ce paradigme. L'estimation d'une tâche logicielle ne peut plus se résumer à une simple question de temps, car nous n'écrivons plus le code de la même manière. Nous passons d'une industrie d'artisans solitaires à une industrie de développeurs augmentés : une collaboration étroite entre l'humain et la machine.
Face à cette mutation, il est temps pour les managers IT et les Tech Leads de repenser l'estimation logicielle. Le coût d'un ticket ne se mesure plus seulement en jours, il se mesure en temps et en tokens.
L'équation du Développeur Augmenté
Aurélien Allienne
L'IA ne détruit pas la charge de travail, elle la convertit. Elle transforme du temps de production laborieux en puissance de calcul (inférence). Par conséquent, nous entrons dans une économie logicielle à double métrique.
Dire qu'un ticket va coûter "4 jours", c'est ignorer la réalité technologique de 2026. La vraie estimation d'une tâche devrait aujourd'hui ressembler à cela :
Cette fonctionnalité nous coûtera 2 jours de temps-cerveau et 800 000 tokens d'inférence.
Modélisons ce nouveau paradigme. Le coût réel d'une fonctionnalité n'est plus linéaire, il répond désormais à l'équation suivante :
Ctotal = (Thumain × Shumain) + (Vtokens × Ptoken)
Où :
- Ctotal représente le coût réel et global de la fonctionnalité.
- Thumain représente le temps de cerveau humain (réflexion, architecture, revue).
- Shumain est le salaire ou coût journalier du développeur.
- Vtokens est le volume de tokens consommés lors des itérations avec l'IA.
- Ptoken est le coût de l'inférence facturé par le fournisseur d'IA.
Le développeur n'est plus un simple producteur de lignes de code. Il devient un orchestrateur de modèles cognitifs externes.
De la théorie à la pratique : Le "GenAI Score"
Pour rendre cette double métrique (Temps + Tokens) lisible et pilotable au quotidien, nous ne pouvons pas demander aux développeurs de deviner à l'avance le nombre exact de tokens qu'ils vont consommer. L'incertitude est trop grande.
La solution que je propose réside dans la création d'un nouvel indicateur lors des rituels d'estimation (Sprint Planning ou Backlog Refinement) : le "GenAI Score".
En plus de l'estimation classique de l'effort humain (en Story Points ou en jours), l'équipe attribue à chaque ticket un score de dépendance à l'intelligence artificielle :
- GenAI-0 (Zéro assistance) : Tâche nécessitant une réflexion architecturale pure, la résolution d'un bug critique en production, ou l'implémentation d'une règle métier très spécifique à l'entreprise. L'IA sera peu ou pas utile.
Impact : consommation de temps humain forte, consommation de tokens nulle.
- GenAI-1 (Assistance de support) : Tâche de développement standard. L'IA sera utilisée comme un copilote classique pour autocompléter la syntaxe, suggérer des optimisations ou générer une première passe de tests unitaires.
Impact : Gain de temps modéré, consommation de tokens moyenne.
- GenAI-2 (Génération massive) : Tâche répétitive ou fastidieuse (création d'un CRUD complet, génération de boilerplate, migration de données structurées d'un format à un autre). L'IA va réaliser 80 % de la frappe au clavier.
Impact : Gain de temps massif, consommation de tokens très forte.
Pourquoi ce score est utile au management ?
Ce simple indicateur offre une visibilité inédite sur la charge et la nature du travail d'un Sprint.
D'abord, il permet un véritable pilotage FinOps : si un Sprint est rempli de tickets "GenAI-2", le manager sait immédiatement que le budget d'inférence (les coûts API ou licences) va exploser sur ces deux semaines, même si la vélocité apparente de l'équipe crève le plafond.
Ensuite, c'est un formidable outil de communication avec le Métier (Product Owners, clients). Si un client s'étonne qu'un ticket prenne 5 jours alors qu'il a "entendu dire que l'IA codait toute seule", le manager peut s'appuyer sur le GenAI Score :
Ce ticket est un GenAI-0. Il touche au cœur de notre réacteur de paiement. L'IA ne peut pas conceptualiser ce risque à notre place, c'est du temps de cerveau humain pur.
Le paradoxe de l'expérience : l'art de l'économie de la pensée
Ce changement de métrique met en lumière un phénomène fascinant : la relation entre la séniorité d'un développeur et sa consommation de ressources machine.
Dans le modèle classique, un développeur junior codait lentement, coûtant cher en temps. Avec l'IA, le risque mute. Un développeur junior face à un problème complexe va souvent tâtonner.
Prenons un exemple concret :
On lui demande d'implémenter
un système d'upload de fichiers Au lieu de concevoir l'architecture (vérification des types, flux asynchrone), il va prompter l'IA de manière vague. Face aux inévitables erreurs d'exécution, il va copier-coller les logs d'erreurs en boucle dans le chat. L'IA va alors générer des "rustines" successives : elle va rajouter des blocs try/catch inutiles, importer des librairies pour résoudre de faux problèmes, et empiler du code mort (des fonctions de validation générées par l'IA mais jamais appelées dans le flux principal). Plus critique encore, à force d'itérations aveugles pour que "ça marche", une faille embarquée peut s'insérer — comme l'oubli de la vérification du type MIME côté serveur —, noyée au milieu de 200 lignes de boilerplate générées automatiquement.
Au final, il résoudra peut-être son ticket en 2 jours, mais en brûlant des millions de tokens dans un ping-pong inefficace avec la machine. C'est ce que l'on pourrait appeler de l'hallucination assistée.
À l'inverse, le développeur senior maîtrise l'art de la commande. Il conceptualise l'architecture en amont et rédige un prompt d'une précision chirurgicale :
# Rôle
Agis en tant que développeur backend expert en Node.js et cybersécurité.
# Contexte
Nous avons une API REST en Express.js avec TypeScript. Je dois implémenter un endpoint d'upload de fichiers pour des documents d'identité.
# Tâche
Rédige le code complet d'un middleware d'upload en utilisant la librairie `multer`, ainsi que le contrôleur associé.
# Contraintes techniques et métier
## 1. Stockage
Utilise `multer.memoryStorage()`. Le fichier ne doit pas être écrit sur le disque local, nous l'enverrons plus tard vers un bucket S3 (tu n'as pas besoin de coder la partie S3).
## 2. Taille
Limite stricte à 5 Mo.
## 3. Format
Uniquement PDF, PNG et JPEG.
## 4. Sécurité (Critique)
- Ne te fie pas uniquement à l'extension du fichier envoyée par le client.
- Utilise une librairie comme `file-type` pour lire les *Magic Numbers* du buffer et valider le vrai type MIME.
- Sanitize le nom du fichier d'origine pour éviter toute faille de type *Path Traversal*.
## 5. Gestion des erreurs
Si le fichier est trop lourd, a le mauvais format, ou manque dans la requête, l'API doit renvoyer une erreur JSON structurée : `{ "error": "CODE_ERREUR", "message": "Description claire" }` avec le code HTTP approprié (400, 413, ou 415). Ne fais pas crasher l'application.
# Livrables attendus
- Le fichier `upload.middleware.ts`
- Le fichier `upload.controller.ts`
- Un fichier `upload.spec.ts` avec les tests unitaires (utilise Jest et Supertest) couvrant les cas nominaux et les erreurs (fichier trop lourd, mauvais type MIME).
> **Règle stricte :** Génère uniquement le code, sans explications superflues.
Il résout le même ticket en ½ journée, en ne consommant beaucoup moins de tokens et en garantissant la sécurité du code.
Le Prompt Engineering n'est pas une compétence de secrétariat glorifiée ; c'est en réalité l'art de l'économie de la pensée. Dans cette ère de la double monnaie, le bon ingénieur est celui qui sait minimiser à la fois son temps de résolution et son empreinte token.
Le risque de dépendance : Quand la machine s'arrête
Accepter cette double métrique et intégrer le GenAI Score à nos pratiques, c'est aussi accepter notre vulnérabilité. Si nous évaluons un ticket à "2 jours + 800k tokens", nous intégrons une dépendance forte à une API tierce.
Que se passe-t-il si, demain, l'accès à notre fournisseur d'IA est coupé, ou si ses tarifs explosent ? Ce sujet dépasse la simple hypothèse technique : c'est un véritable enjeu de fragilité systémique. Cette préoccupation rejoint directement les alertes du CIGREF sur la souveraineté numérique. Dans ses recommandations pour une Intelligence artificielle fiable, l'institution souligne que :
Ces modèles doivent s’appuyer sur des infrastructures informatiques européennes et veiller à rester exempts de régimes juridiques extraterritoriaux.
Déléguer une part critique de notre production intellectuelle à des modèles propriétaires fermés et étrangers crée une vulnérabilité majeure. Le risque de "vendor lock-in" n'est plus seulement infrastructurel (hébergement cloud) : il est devenu cognitif.
Si l'outil tombe en panne, le temps perdu n'est pas qu'une simple soustraction mathématique. Le ticket de "2 jours avec IA" ne redevient pas magiquement le "4 jours sans IA" du passé.
La réalité est bien plus cruelle :
- Le coût de la perte de Flow : Le développeur, habitué à la complétion instantanée, fait face au syndrome de la page blanche. Le muscle de l'écriture pure (le boilerplate, la syntaxe précise des frameworks) s'atrophie inévitablement quand il n'est plus exercé quotidiennement.
- L'opacité du code généré : Si le développeur doit reprendre "à la main" une Pull Request partiellement générée par une IA qu'il ne peut plus interroger pour en comprendre les nuances, la charge de rétro-ingénierie explose.
- L'effondrement des prévisions : Un Sprint Agile planifié sur une vélocité "sous stéroïdes" (grâce à l'IA) s'effondrera instantanément si la connexion au LLM est rompue le mardi matin. Un ticket de 2 jours passera potentiellement à 6 jours.
En tant que managers, il devient impératif d'estimer un indice de résilience. Sommes-nous capables, en cas de crise, de livrer la feature critique sans assistance, ou notre équipe a-t-elle désappris à marcher sans sa béquille algorithmique ?
Gérer l'énergie plutôt que le temps
L'estimation d'un projet IT de demain ne consistera plus à remplir des diagrammes de Gantt ou à compter des points de complexité isolés. Elle consistera à gérer un budget global d'énergie.
Qu'achetons-nous réellement lorsque nous laissons une équipe dépenser des millions de tokens sur un Sprint ?
Achetons-nous de l'élimination de dette technique ? Du confort mental pour nos développeurs, en délestant l'IA de l'écriture fastidieuse des tests unitaires ? Ou subventionnons-nous une paresse intellectuelle qui se traduira par des systèmes illisibles et inmaintenables à long terme ?
Le manager de demain ne demandera plus « Combien de temps cela va-t-il prendre ? ». Il demandera « Quel est le juste équilibre entre l'effort de notre équipe et l'inférence de la machine pour ce problème précis ? ».
Notre métier change. Il est grand temps que nos méthodes d'estimation en fassent de même.
