En bref. Chaque automatisation est un prêt. Vous récupérez du temps aujourd’hui et vous payez des intérêts plus tard : vérifier les résultats, traiter les exceptions, réparer les pannes et garder quelqu’un capable de faire le travail à la main. Nous appelons le solde impayé la dette d’automatisation. Les preuves que ces intérêts sont réels sont solides : dans un essai randomisé, des développeurs open source expérimentés prévoyaient que les outils d’IA réduiraient leur temps de travail de 24 % et ont en réalité mis 19 % plus longtemps ; le rapport DORA 2024 de Google estime que chaque hausse de 25 % de l’adoption de l’IA s’accompagne d’une baisse de 1,5 % du débit de livraison et de 7,2 % de la stabilité des livraisons ; et 66 % des développeurs interrogés dans l’enquête Stack Overflow 2025 citent les résultats d’IA « presque justes, mais pas tout à fait » comme leur principale frustration. Notre modèle de seuil de rentabilité appliqué à cinq automatisations courantes montre qu’une fois la vérification, les exceptions et la maintenance comptabilisées, deux d’entre elles ne sont jamais rentables et une troisième a besoin de plus de trois ans. La solution n’est pas de moins automatiser. C’est un jugement de dirigeant sur ce qu’il faut automatiser, associé à la discipline de l’étudiant qui apprend un processus à la main avant de le confier à une machine.
Le prêt que personne ne consigne
Ward Cunningham a introduit la métaphore de la dette en 1992, dans son retour d’expérience présenté à OOPSLA sur le système de gestion de portefeuille WyCash. Livrer du code écrit pour la première fois, expliquait-il, revient à s’endetter : un peu de dette accélère le développement tant qu’elle est remboursée rapidement, mais chaque minute passée sur du code pas tout à fait juste compte comme un intérêt, et une organisation peut être paralysée sous ce poids. Vingt-trois ans plus tard, une équipe de Google dirigée par D. Sculley a appliqué la même grille de lecture à l’apprentissage automatique dans l’article NeurIPS « Hidden Technical Debt in Machine Learning Systems ». Leur avertissement initial vaut pour tout projet d’automatisation : il est dangereux de considérer les gains rapides comme gratuits, car les systèmes réels entraînent couramment des « coûts de maintenance continus massifs ». Ils ajoutent que toute dette n’est pas mauvaise, mais que toute dette doit être servie, et que la dette cachée est dangereuse parce qu’elle s’accumule en silence.
La dette d’automatisation est le même phénomène à l’échelle du flux de travail d’une personne ou d’une équipe. Un Zap, un script, un agent d’IA, une règle de messagerie ou une macro de tableur supprime chacun une tâche visible et en crée d’autres, moins visibles :
- quelqu’un doit vérifier que le résultat est correct ;
- quelqu’un doit rattraper les cas que l’automatisation ne sait pas traiter ;
- quelqu’un doit la réparer quand une API, un formulaire, un nom de colonne ou un modèle change ;
- quelqu’un doit se souvenir du fonctionnement du processus pour le jour où l’automatisation tombe en panne.
Lorsque personne n’est responsable de ces quatre tâches, l’automatisation ressemble à un pur bénéfice le jour de sa mise en service, puis se transforme en fuite lente. Le plus dangereux est que cette fuite apparaît rarement au même endroit que l’économie. La personne qui a construit le flux annonce les heures gagnées ; celle qui corrige ses erreurs n’annonce rien, parce que personne ne le lui a demandé.
Ce que disent les données sur les intérêts cachés
Trois jeux de données indépendants, issus d’un essai randomisé, d’une vaste enquête sectorielle et d’une très grande enquête auprès des développeurs, vont dans le même sens. Le tableau 1 ne reprend que des chiffres que nous avons confirmés dans les documents d’origine.
Tableau 1. Preuves que l’automatisation comporte des coûts cachés (données vérifiées)
| Source | Échantillon | Résultat |
|---|---|---|
| Essai contrôlé randomisé METR (Becker et al., 2025) | 16 développeurs expérimentés, 246 tâches réelles dans des projets open source matures | Les développeurs prévoyaient que l’IA réduirait le temps de réalisation de 24 % ; après coup, ils estimaient une réduction de 20 % ; l’effet mesuré était une hausse de 19 % du temps de réalisation |
| Même étude, analyse de fiabilité (annexe C.1.4) | Enregistrements d’écran de 44 tickets avec des étiquettes valides | Les développeurs ont accepté moins de 44 % des générations de l’IA et consacré environ 9 % du temps autorisé avec IA à relire et nettoyer ses résultats ; 75 % ont déclaré lire chaque ligne du code produit par l’IA |
| Google DORA, Accelerate State of DevOps 2024 | Près de 3 000 professionnels interrogés en 2024 | Pour chaque hausse de 25 % de l’adoption de l’IA : débit de livraison estimé à -1,5 %, stabilité des livraisons -7,2 %, temps consacré au travail à valeur ajoutée -2,6 %, temps consacré aux tâches ingrates +0,4 % |
| Google DORA 2024, confiance | Même enquête | 39,2 % déclarent peu (27,3 %) ou pas (11,9 %) de confiance dans la qualité du code généré par l’IA |
| Enquête Stack Overflow auprès des développeurs 2025 | Des dizaines de milliers de développeurs (33 244 ont répondu à la question sur la confiance) | 46 % se méfient de l’exactitude des outils d’IA contre 33 % qui lui font confiance ; 66 % citent les résultats « presque justes, mais pas tout à fait » comme une frustration et 45,2 % estiment que déboguer du code généré par l’IA prend plus de temps ; 20 % disent être devenus moins confiants dans leur propre capacité à résoudre des problèmes |
Lus ensemble, ces chiffres décrivent l’anatomie de la dette d’automatisation.
L’écart de perception est le premier versement d’intérêts. Dans l’essai METR, les développeurs n’étaient pas des débutants : ils comptaient en moyenne cinq ans d’expérience sur les dépôts sur lesquels ils travaillaient, et ils croyaient encore après l’étude que l’IA les avait rendus plus rapides. Si des experts se trompent sur le signe de l’effet sur leur propre travail, une estimation approximative des « heures gagnées » par une nouvelle automatisation est une preuve fragile. Les auteurs prennent soin de préciser que leur résultat s’applique à un contexte précis (développeurs expérimentés, grandes bases de code matures, outils de début 2025) et qu’il ne faut pas le lire comme « l’IA ralentit tout le monde ». La leçon transposable est plus étroite et plus utile : la vitesse ressentie n’est pas la vitesse mesurée.
La vérification est un coût récurrent, pas ponctuel. Accepter moins de la moitié des générations, passer environ un dixième du temps à relire et nettoyer, lire chaque ligne : voilà à quoi ressemble la vérification quand le responsable a des exigences élevées. Les données Stack Overflow montrent le même schéma chez des dizaines de milliers de développeurs : un résultat presque juste coûte cher, parce qu’il faut repérer l’erreur, la comprendre et la corriger.
La vitesse locale peut nuire aux résultats du système. Le constat de DORA est le plus contre-intuitif. L’adoption de l’IA était associée à une meilleure qualité de la documentation, à une meilleure qualité du code et à une productivité individuelle accrue, mais aussi à un débit et à une stabilité des livraisons dégradés. L’hypothèse du rapport est que la génération plus rapide a poussé les équipes à oublier l’un des principes les plus fondamentaux de DORA, les petits lots : si l’IA permet de produire plus de code dans le même temps, les ensembles de modifications grossissent probablement, et DORA a constamment observé que les changements plus volumineux sont plus lents et plus sujets à l’instabilité. Le rapport a aussi constaté que le temps consacré au travail à valeur ajoutée diminuait tandis que le temps passé sur les tâches ingrates restait inchangé, soit l’inverse de ce que promet l’automatisation. Pour quiconque automatise un flux de travail, l’avertissement est clair : des étapes plus rapides ne garantissent pas un système plus rapide.
Ces constats viennent du logiciel, où la mesure est particulièrement fiable. Nous les utilisons comme le cas le mieux mesuré d’un schéma que la littérature sur les facteurs humains a décrit des décennies plus tôt pour l’automatisation en général, et sur lequel nous revenons plus bas.
Le vrai calcul du ROI : un modèle de seuil de rentabilité
La plupart des décisions d’automatisation reposent sur un calcul naïf : minutes gagnées par exécution, multipliées par le nombre d’exécutions par an, moins le temps de construction. Le tableau 2 recalcule cinq automatisations courantes du travail intellectuel en ajoutant trois termes : les minutes de vérification par exécution, un taux d’exceptions avec un temps de traitement manuel, et des heures de maintenance par mois. Les données d’entrée sont des hypothèses illustratives choisies pour être réalistes dans une petite équipe, pas des mesures ; ce qui compte est la forme du résultat, et vous pouvez refaire le calcul avec vos propres chiffres.
Tableau 2. Calcul CEOtudent : rendement naïf et rendement réel la première année de cinq automatisations (heures)
| Automatisation | Minutes gagnées par exécution | Exécutions par an | Heures de construction | Économie brute naïve | Net naïf an 1 | Coûts cachés (part du brut) | Net réel an 1 | Seuil de rentabilité naïf (semaines) | Seuil de rentabilité réel (semaines) |
|---|---|---|---|---|---|---|---|---|---|
| Compilation du rapport hebdomadaire | 45 | 52 | 6 | 39,0 | +33,0 | 23,3 (60 %) | +9,7 | 8,0 | 19,8 |
| Tri quotidien de la boîte de réception | 10 | 260 | 8 | 43,3 | +35,3 | 51,1 (118 %) | -15,8 | 9,6 | jamais |
| Rapprochement mensuel des factures | 120 | 12 | 12 | 24,0 | +12,0 | 20,4 (85 %) | -8,4 | 26,0 | 173,3 |
| Enrichissement CRM par prospect | 3 | 2 080 | 10 | 104,0 | +94,0 | 88,0 (85 %) | +6,0 | 5,0 | 32,5 |
| Mise en forme trimestrielle du dossier du conseil | 90 | 4 | 10 | 6,0 | -4,0 | 8,3 (139 %) | -12,3 | 86,7 | jamais |
Hypothèses (minutes de vérification par exécution / taux d’exceptions x minutes manuelles par exception / heures de maintenance par mois) : rapport hebdomadaire 10 / 10 % x 30 / 1 ; tri de la boîte de réception 4 / 15 % x 15 / 2 ; rapprochement des factures 30 / 20 % x 60 / 1 ; enrichissement CRM 1 / 5 % x 10 / 3 ; dossier du conseil 20 / 25 % x 60 / 0,5. Coûts cachés = vérification + exceptions + maintenance par an. Seuil de rentabilité réel = heures de construction divisées par l’économie nette récurrente annuelle, multipliées par 52 ; « jamais » signifie que l’économie nette récurrente est nulle ou négative.
Quatre schémas se dégagent.
- Chaque calcul naïf ressemblait à un gain, sauf un. Quatre des cinq automatisations affichent un net positif la première année selon la méthode naïve. Selon la méthode réelle, seules deux restent positives, et toutes deux reculent fortement : le rapport hebdomadaire passe de +33,0 à +9,7 heures et l’enrichissement CRM de +94,0 à +6,0.
- Une fréquence élevée ne sauve pas une tâche bruitée. Le tri de la boîte de réception s’exécute 260 fois par an et fait gagner 10 minutes à chaque fois, mais quatre minutes de vérification par exécution, un taux d’exceptions de 15 % et deux heures par mois de correction des règles absorbent 118 % de l’économie brute. Il n’est jamais rentable.
- Faible fréquence plus coût de construction élevé : le piège classique. Le dossier trimestriel du conseil ne peut pas être rentable même selon la méthode naïve, et chaque exécution a une chance sur quatre de nécessiter une heure de sauvetage manuel.
- La maintenance est le terme qui fait basculer le résultat. L’automatisation des factures passe d’un retour sur investissement naïf de six mois à plus de trois ans, principalement à cause de 12 heures de maintenance par an face à seulement 24 heures d’économie brute.
Le tableau 3 montre à quel point même une automatisation saine est sensible aux deux termes cachés que l’on oublie le plus souvent.
Tableau 3. Calcul CEOtudent : heures nettes réelles la première année pour l’automatisation du rapport hebdomadaire, selon la charge de maintenance et de vérification
| Heures de maintenance par mois | 0 min de vérification par exécution | 10 min | 20 min | 30 min |
|---|---|---|---|---|
| 0 | +30,4 | +21,7 | +13,1 | +4,4 |
| 0,5 | +24,4 | +15,7 | +7,1 | -1,6 |
| 1 | +18,4 | +9,7 | +1,1 | -7,6 |
| 2 | +6,4 | -2,3 | -10,9 | -19,6 |
| 3 | -5,6 | -14,3 | -22,9 | -31,6 |
Paramètres constants : 45 minutes gagnées par exécution, 52 exécutions par an, 6 heures de construction et un taux d’exceptions de 10 % à 30 minutes chacune.
La même automatisation va d’un gain de 30 heures à une perte de 32 heures selon deux chiffres qui figurent rarement dans un dossier d’investissement. Si vous ne savez pas encore les estimer, vous ne connaissez pas assez le processus pour l’automatiser. C’est le cœur de l’argument qui suit.
Les six composantes de la dette d’automatisation
La dette a plus d’une origine. Le tableau 4 nomme les composantes que nous utilisons, leur manifestation dans le travail quotidien et les recherches auxquelles chacune fait écho.
Tableau 4. Cadre éditorial CEOtudent : les six composantes de la dette d’automatisation
| Composante | Ce qui s’accumule | Signal d’alerte précoce | Écho dans la recherche |
|---|---|---|---|
| 1. Dette de maintenance | Réparations lorsque les entrées, les outils, les API, les prompts ou les modèles changent | « C’est encore cassé » apparaît dans la messagerie plus d’une fois par trimestre | Sculley et al. : code de liaison et « Changing Anything Changes Everything » |
| 2. Dette d’exceptions | Traitement manuel des cas que l’automatisation ne sait pas gérer | Un dossier « à vérifier » qui grossit et que personne ne vide | Bainbridge : l’opérateur hérite des tâches que le concepteur n’a pas pu automatiser |
| 3. Dette de vérification | Temps passé à contrôler un résultat presque juste | Vous relisez chaque résultat « au cas où » | METR : moins de 44 % des générations acceptées, environ 9 % du temps passé à relire |
| 4. Dette de dépendance | Couplage caché : d’autres flux ou d’autres personnes commencent à dépendre du résultat | Quelqu’un que vous n’attendiez pas se plaint quand cela s’arrête | Sculley et al. : consommateurs non déclarés et boucles de rétroaction cachées |
| 5. Dette de compétences | Érosion de la capacité à faire, juger ou rattraper la tâche à la main | Personne ne sait faire la tâche manuellement quand l’automatisation tombe en panne | Bainbridge : les compétences se dégradent faute d’usage ; Stack Overflow 2025 : 20 % ont moins confiance en leur propre capacité à résoudre des problèmes |
| 6. Dette de responsabilité | Aucun responsable désigné, aucun budget, aucune date de retrait | Vous ne savez pas dire qui remarquerait une panne silencieuse | Parasuraman et Riley : « abus » d’automatisation par les concepteurs et les managers |
Deux d’entre elles méritent plus d’attention, parce que ce sont les moins visibles.
La dette de compétences est l’ironie au cœur de l’automatisation. L’article de Lisanne Bainbridge « Ironies of Automation », publié en 1983 dans Automatica, a posé le problème quatre décennies avant l’IA générative. Automatiser un processus laisse généralement deux tâches à l’humain : surveiller que le système automatique fonctionne et reprendre la main quand ce n’est pas le cas. Or reprendre la main exige précisément les compétences qui s’étiolent quand une personne ne fait que surveiller : les compétences physiques se détériorent lorsqu’elles ne sont pas utilisées, et les connaissances nécessaires aux situations inhabituelles ne se développent que par la pratique et le retour d’information. Elle notait aussi, en s’appuyant sur la recherche sur la vigilance, que même une personne très motivée ne peut maintenir une attention efficace plus d’une demi-heure environ sur une source où il se passe très peu de chose. Son ironie est que plus l’automatisation est avancée, plus la contribution humaine peut devenir cruciale, précisément au moment où cet humain a eu le moins d’entraînement.
La dette de responsabilité est là où le management se trompe. Dans leur article de 1997 publié dans Human Factors, Raja Parasuraman et Victor Riley distinguaient quatre manières dont les personnes se rapportent à l’automatisation. Comme le résume leur résumé, le mésusage est une dépendance excessive, qui entraîne des défaillances de surveillance et des biais de décision ; la désaffection est une négligence, souvent causée par de fausses alertes ; et l’abus consiste à automatiser des fonctions « sans égard suffisant pour les conséquences sur la performance humaine », ce qui définit le rôle des personnes comme un sous-produit de l’automatisation. Pour un manager ou un indépendant, l’abus est le plus pertinent : automatiser parce qu’un outil le permet, puis supposer que ceux qui restent absorberont les exceptions et la vérification.
La grille Automatiser maintenant / Attendre / Jamais
La règle de décision ci-dessous transforme les six composantes en liste de contrôle notée. Attribuez 0, 1 ou 2 points à chaque question avant de construire quoi que ce soit.
Tableau 5. Cadre éditorial CEOtudent : grille d’évaluation de la dette d’automatisation
| Question | 0 point | 1 point | 2 points |
|---|---|---|---|
| Fréquence : à quelle fréquence la tâche s’exécute-t-elle ? | Moins d’une fois par mois | 1 à 8 fois par mois | Plus de 8 fois par mois |
| Stabilité : le processus a-t-il changé au cours des 3 derniers mois ? | Il a changé, et rien n’est écrit | Stable mais non documenté | Stable et rédigé sous forme de mode opératoire |
| Vérification : combien de temps prend le contrôle d’un résultat, par rapport à la tâche faite à la main ? | Plus de 30 % | 10 % à 30 % | Moins de 10 % |
| Exceptions : quelle part des exécutions nécessite un humain ? | Plus de 20 % | 5 % à 20 % | Moins de 5 % |
| Coût de l’erreur : si le résultat est faux sans que personne ne le voie, que se passe-t-il ? | Il atteint un client, un régulateur ou un paiement | Il est repéré en aval, avec un certain coût | Il est repéré à peu de frais et sans dommage |
| Responsabilité : existe-t-il un responsable désigné disposant de temps pour la maintenance ? | Personne | Un responsable, mais sans temps prévu | Responsable désigné, temps prévu, date de revue fixée |
| Compétence : quelqu’un sait-il encore faire et juger la tâche à la main ? | Personne ne le pourrait | Une personne, sans pratique récente | Oui, et la compétence reste entretenue |
Règle de décision (14 points au maximum) :
- Automatiser maintenant : 10 points ou plus, et aucun zéro sur Coût de l’erreur ou Responsabilité.
- Attendre et apprendre : 6 à 9 points, ou un zéro sur Stabilité ou Responsabilité. Exécutez la tâche manuellement encore quelques fois, rédigez la procédure, mesurez le temps de vérification et le taux d’exceptions, désignez un responsable, puis refaites l’évaluation.
- Jamais (pour l’instant) : 5 points ou moins, ou un zéro à la fois sur Coût de l’erreur et sur Vérification. Ce sont des tâches où les erreurs coûtent cher et sont difficiles à repérer : gardez un humain aux commandes et n’utilisez les outils qu’en assistance.
Deux choix de conception sont délibérés. D’abord, Responsabilité et Coût de l’erreur agissent comme des vetos, car un total élevé ne compense ni une automatisation que personne n’entretient ni des erreurs silencieuses qui atteignent un client. Ensuite, la Stabilité obtient plus de points quand le processus est écrit, car un processus que vous ne savez pas décrire est un processus que vous ne pouvez pas vérifier. Si vous n’avez pas encore cartographié le travail, commencez par l’audit de flux de travail en 7 étapes, puis transformez le résultat en procédure écrite selon l’approche décrite dans la renaissance des modes opératoires normalisés. La grille complète, sans la remplacer, une méthode de priorisation comme la règle des 80/20 pour savoir quelles tâches du travail intellectuel automatiser en premier : la lecture 80/20 vous dit où se trouve la valeur, et la grille de la dette vous dit si vous pouvez la récolter.
La lecture CEO+Student : apprendre le processus avant de l’automatiser
Un dirigeant n’approuve pas un investissement sans demander ce qu’il coûtera à faire fonctionner. L’automatisation est un investissement avec des coûts d’exploitation, et le rôle du responsable est de les voir tous : les heures de construction inscrites dans la proposition, les heures de vérification et de réparation qui atterrissent sur le bureau de quelqu’un d’autre, et la capacité que l’organisation perd si plus personne ne pratique la tâche. Un jugement de dirigeant consiste à poser trois questions auxquelles toute proposition d’automatisation devrait répondre :
- Qui la vérifie, comment, et combien de temps cela prend-il ? Si la réponse est « personne » ou « on verra », la dette de vérification n’a pas de prix. Placer des points de contrôle délibérés est une tâche de conception, traitée dans la supervision humaine par conception.
- Qui en est responsable quand elle tombe en panne, et quand déciderons-nous de la garder ou non ? Une automatisation sans date de revue est un abonnement sans bouton de résiliation.
- Qu’advient-il de notre compétence ? S’il s’agit d’une tâche où le jugement est le produit, comme la tarification, le recrutement, le conseil client ou l’édition, automatiser la tâche entière épuise l’expertise nécessaire pour juger le résultat.
La moitié « étudiant » de la thèse est la défense pratique. Le moyen le plus fiable d’éviter la dette d’automatisation est de comprendre un processus à la main avant de l’automatiser : le faire assez de fois pour en connaître les exceptions, chronométrer l’étape de vérification, rédiger la procédure, et seulement ensuite décider. Les développeurs de l’étude METR avaient des années d’expérience sur leurs dépôts et ont pourtant été surpris ; quelqu’un qui automatise un processus qu’il n’a exécuté que deux fois dispose de bien moins d’éléments. Apprendre d’abord protège aussi contre l’ironie de Bainbridge. Si vous avez fait le travail vous-même et continuez à le faire de temps en temps, vous pouvez encore juger le résultat de l’automatisation et la rattraper quand elle échoue. Construire ce jugement est une compétence à part entière, décrite dans la compétence d’évaluation pour juger les sorties d’IA.
L’opportunité est réelle : dans le tableau 2, deux des cinq automatisations restent rentables en moins d’un an. Les tâches stables, fréquentes et peu coûteuses à vérifier sont celles où l’automatisation se rentabilise. Les gagnantes se choisissent, elles ne se présument pas.
Comment rembourser la dette d’automatisation que vous avez déjà
La plupart des lecteurs font déjà tourner des automatisations. Une revue trimestrielle en quatre étapes permet de garder le solde sous contrôle :
- Inventorier. Listez chaque automatisation, y compris les règles de messagerie, les scripts planifiés, les agents d’IA et les flux sans code. En face de chacune, notez le responsable et la dernière date à laquelle quelqu’un a vérifié qu’elle fonctionnait. Les cases vides sont de la dette de responsabilité.
- Mesurer les intérêts. Pendant une semaine type, notez pour chaque automatisation les minutes passées à vérifier les résultats, à traiter les exceptions et à réparer les pannes. Intégrez ces chiffres dans la formule du tableau 2.
- Refinancer ou retirer. Les automatisations qui ne sont plus rentables ont trois options : les simplifier (moins d’étapes, moins de dépendances), les restreindre aux cas qui fonctionnent de manière fiable et orienter le reste vers un humain, ou les désactiver. Désactiver une automatisation qui coûte plus qu’elle ne rapporte est un gain, pas un échec.
- Garder la compétence vivante. Pour tout ce qui est critique, demandez au responsable d’exécuter la tâche manuellement de temps en temps, afin que la solution de repli existe le jour où elle est nécessaire.
Cette revue s’intègre naturellement dans la couche de maintenance d’une journée de travail structurée ; voir le flux de travail IA en 5 couches pour savoir où la placer.
FAQ
Qu’est-ce que la dette d’automatisation ?
La dette d’automatisation est le travail futur accumulé que crée l’automatisation d’une tâche : vérifier les résultats, traiter les exceptions, entretenir l’automatisation quand les choses changent, gérer ce qui en dépend et préserver la compétence humaine nécessaire en cas de panne. C’est un cadre CEOtudent qui étend la métaphore de la dette technique de Ward Cunningham du code aux flux de travail.
La dette d’automatisation est-elle toujours mauvaise ?
Non. Comme une dette financière, elle peut être un choix judicieux si le rendement dépasse les intérêts et si quelqu’un en assure le service. Dans notre modèle de seuil de rentabilité, l’automatisation d’un rapport hebdomadaire rapporte encore 9,7 heures nettes la première année, une fois tous les coûts cachés déduits. Le problème, c’est la dette sans prix et sans responsable.
L’automatisation par l’IA aggrave-t-elle le problème ?
Elle le peut, car les résultats de l’IA sont souvent « presque justes », ce qui alourdit la charge de vérification. Dans l’enquête Stack Overflow 2025, 66 % des développeurs citaient cela comme une frustration, et dans l’essai METR, les développeurs ont accepté moins de 44 % des générations de l’IA. L’IA accélère aussi la construction d’automatisations, ce qui facilite l’endettement sans qu’on s’en aperçoive.
Comment savoir si une automatisation coûte plus qu’elle ne rapporte ?
Notez pendant une semaine le temps de vérification, de traitement des exceptions et de réparation, annualisez-le et soustrayez-le du temps brut gagné. Si le net récurrent est nul ou négatif, l’automatisation ne remboursera jamais son temps de construction, comme pour deux des cinq exemples du tableau 2.
Faut-il arrêter d’automatiser tant que je ne maîtrise pas chaque processus ?
Non. Utilisez la grille : les tâches stables, fréquentes, peu coûteuses à vérifier et dotées d’un responsable désigné peuvent être automatisées dès maintenant. La catégorie « attendre » signifie simplement apprendre le processus à la main, le mettre par écrit et le mesurer avant de construire.
Sources
- Becker, J., Rush, N., Barnes, B., and Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR. arXiv:2507.09089v2.
- Google Cloud DORA (2024). Accelerate State of DevOps Report 2024 (v. 2024.3).
- Stack Overflow (2025). 2025 Developer Survey, section IA.
- Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., and Dennison, D. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28 (NeurIPS 2015).
- Bainbridge, L. (1983). Ironies of Automation. Automatica, 19(6), 775-779.
- Parasuraman, R., and Riley, V. (1997). Humans and Automation: Use, Misuse, Disuse, Abuse. Human Factors, 39(2), 230-253 (résumé).
- Cunningham, W. (1992). The WyCash Portfolio Management System. OOPSLA ‘92 Experience Report.
Le tableau 1 présente des chiffres vérifiés issus de l’essai METR, du rapport DORA 2024 et de l’enquête Stack Overflow 2025. Les tableaux 2 et 3 sont des calculs CEOtudent fondés sur les hypothèses d’entrée illustratives indiquées sous chaque tableau ; chaque cellule a été calculée par script puis revérifiée de manière indépendante. Les tableaux 4 et 5 relèvent du cadre éditorial CEOtudent ; les échos de la recherche dans le tableau 4 signalent des résultats apparentés, et non une validation du cadre.
Ce contenu a été compilé avec le soutien de l’IA à la suite d’une recherche approfondie, puis rédigé et préparé pour publication par l’équipe éditoriale de CEOtudent.
This post is also available in:
