i

Description

Un petit ordinateur d'échecs électronique en pleine partie, pièces blanches et noires sur l'échiquier.

Source

Dezidor · page d’origine

Licence

PD Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

La loi de Hofstadter

Même quand on sait qu'on est en retard par nature et qu'on se garde de la marge, on est encore en retard.

En bref

• Quoi : une tâche complexe prend toujours plus de temps que prévu, même si l'on a tenu compte de cette règle.
• Pourquoi : l'autoréférence : la correction qu'on applique est elle-même estimée avec le même optimisme que l'estimation d'origine.
• Détecter : « on a déjà mis de la marge », et pourtant le retard arrive.
• Éviter : corriger avec ses données et non avec son impression, découper, livrer tôt, revoir l'estimation en cours de route.

Sur cette page

1. Définition
2. Le mécanisme
3. Où on le rencontre
   1. En conduite de projet
   2. En management
4. Cas célèbres
   1. « Dans dix ans, un ordinateur sera champion du monde d'échecs » 1957-1997
   2. La règle des 90-90 et la loi de Brooks 1975-1985
5. Signaux de détection
6. Réflexes d'évitement
7. Avec l'IA : détecter, remédier, atténuer
   1. Détecter
   2. Remédier
   3. Atténuer
   4. Prompts à intégrer à vos usages
   5. Comment les intégrer
   6. Précautions
8. Limites
9. Sources et vérification
10. Voir aussi
    1. Se combine avec, ou renforce
    2. Biais voisins
    3. Contrepoids et réflexes associés

Définition#

Illustration fictive

La loi de Hofstadter s'énonce ainsi : « Il faut toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter. » Elle est due à Douglas Hofstadter, qui l'a formulée dans Gödel, Escher, Bach : les brins d'une guirlande éternelle (1979), à propos de la prévision du moment où un ordinateur battrait les meilleurs joueurs d'échecs humains.

C'est une adage empirique et volontairement paradoxal, pas un biais cognitif au sens strict ni une loi scientifique démontrée. Sa force est son autoréférence : elle est vraie parce qu'elle s'applique à elle-même. Elle rappelle que l'on ne s'en sort pas en ajoutant une marge « à l'intuition », puisque l'intuition qui fixe la marge est celle-là même qui s'est trompée. Elle est proche de l'erreur de planification, dont elle décrit l'effet persistant, et de l'optimisme irréaliste, dont elle décrit l'un des moteurs.

Le mécanisme#

Aucune expérience n'a « prouvé » la loi ; on peut en revanche expliquer pourquoi elle est souvent vérifiée :

• Récursion de l'optimisme : on corrige son estimation (« ajoutons 20 % »), mais la correction est elle-même décidée avec l'optimisme qui a produit l'estimation. Le correctif reste trop petit.
• Les imprévus ne sont pas imaginables à l'avance : on ajoute une marge pour des risques connus, pas pour ceux qu'on ne voit pas encore.
• La queue de distribution est lourde : le temps réel d'une tâche n'est pas symétrique autour de la moyenne ; quelques dépassements très importants tirent la moyenne vers le haut, et la marge calée sur « un dépassement raisonnable » ne les couvre pas.
• Effet de la marge elle-même : une marge connue peut être consommée (loi de Parkinson : le travail s'étale pour occuper le temps disponible), de sorte qu'on ne la retrouve pas à la fin.
• La proportion trompeuse : on estime la partie visible d'une tâche ; la dernière part du travail (intégration, tests, finitions) prend bien plus de temps que le début ne le laissait croire. C'est la « règle des 90-90 » attribuée à Tom Cargill, des Bell Labs : les 90 premiers pour cent du code prennent 90 % du temps, les 10 derniers pour cent en prennent les 90 % restants.

Où on le rencontre#

En conduite de projet#

• Chiffrage : « j'ai déjà pris du buffer » ; le buffer est lui-même sous-estimé par rapport à l'historique.
• Planning de release : la date est repoussée trois fois, chaque fois de « deux semaines », jamais de ce que dit la vitesse constatée.
• Les 10 derniers pour cent : le projet est « presque terminé » depuis des semaines ; la fin (recette, correctifs, mise en production) est ce qui prend le plus de temps.
• Estimation en points : la vélocité est calibrée sur les sprints passés, mais l'on s'engage sur la meilleure vélocité observée, pas sur la médiane.
• Dépendances externes : on ajoute une marge pour son propre travail, pas pour l'attente d'une décision du client ou d'une livraison de tiers.

En management#

• Engagements devant la direction : on donne une date « avec marge », on est quand même obligé de la repousser, et la confiance s'érode.
• Plans de transformation : la durée d'adoption d'un outil ou d'une méthode est revue à la hausse à chaque jalon.
• Délégation : on demande à un collaborateur « de combien de temps il a besoin », on ajoute la marge qu'on juge raisonnable, et on est surpris du retard.
• Recrutement : le délai « pour trouver et intégrer quelqu'un » s'allonge à chaque fois qu'on ne tient pas compte du délai d'autonomie réelle.

Cas célèbres#

Signaux de détection#

• « On a déjà mis de la marge. » Et l'on dépasse quand même.
• La date a été repoussée plusieurs fois, chaque fois de la même durée (« deux semaines de plus »).
• L'avancement est « 90 % » depuis plusieurs semaines.
• La marge n'est justifiée par aucune donnée : « on prend 20 % », « on double ».
• Personne ne sait quel pourcentage de dépassement l'équipe a connu sur ses trois derniers projets.
• La marge d'une tâche est consommée dès le début (le travail s'étale), et le retard s'accumule à la fin.

Réflexes d'évitement#

1. Corriger avec des données, pas avec une règle de pouce. Calculez le ratio réel/estimé de vos derniers projets (médiane et 80^e percentile) et appliquez-le, au lieu d'ajouter « un peu de marge ».
2. Réviser l'estimation en cours de route. Après chaque jalon, recalculez la fin à partir de la vitesse constatée et non de la vitesse espérée.
3. Livrer tôt et par petits morceaux. Un lot court est plus facile à estimer ; le retard se voit dès le premier lot plutôt qu'à la fin.
4. Chiffrer la fin séparément. Réservez un poste explicite à l'intégration, à la recette, à la correction des anomalies et à la mise en production.
5. Annoncer une fourchette et un niveau de confiance. « Entre 10 et 16 semaines, 80 % de confiance » vaut mieux qu'une date à laquelle on appliquerait une marge invisible.
6. Réduire le périmètre plutôt que la qualité. Quand le retard apparaît, sacrifiez des fonctionnalités, pas la recette ni les tests.
7. Mettre la marge au niveau du projet, pas de la tâche. Une réserve globale, gérée par le responsable, est moins consommée qu'une marge cachée dans chaque tâche.

Avec l'IA : détecter, remédier, atténuer#

Prompts à intégrer à vos usages#

1. Corriger l'estimation avec l'historique. À utiliser avec un export de vos estimations et durées réelles.

Voici l'historique de nos lots passés (estimation initiale, durée réelle, type de lot) : [tableau].
1. Calcule, pour chaque type de lot, le ratio durée réelle / durée estimée : minimum, médiane, 80<sup>e</sup> percentile, maximum.
2. Dis quelles conclusions sont fiables et lesquelles reposent sur trop peu de lots.
3. Pour un nouveau lot estimé à [valeur], donne la durée à annoncer pour « une chance sur deux » et pour « quatre chances sur cinq ».
N'invente aucune donnée : si l'historique est insuffisant, dis-le.

2. Réviser la date en cours de projet. À chaque jalon, avec les chiffres réellement constatés.

Situation : [travail restant en unités], vitesse constatée sur les [N] derniers sprints : [valeurs], date de livraison actuelle : [date].
Calcule une date de fin probable avec une fourchette (optimiste, probable, pessimiste) à partir de la <em>vitesse constatée</em>, pas de la vitesse espérée.
Précise ce qui rendrait cette projection trop optimiste (fin de projet, dépendances externes, correctifs) et propose trois décisions de réduction de périmètre pour tenir la date si elle est imposée.

Comment les intégrer#

• Au chiffrage : le prompt 1 sert à corriger une estimation par l'historique, avant de l'annoncer.
• À chaque jalon : le prompt 2 remplace le « on rattrapera » par une projection chiffrée.
• En rétrospective : conservez les résultats pour enrichir l'historique : c'est lui, et non l'IA, qui corrige le biais.

Précautions#

• Un historique trop court ou biaisé (seuls les projets terminés) donne des corrections trompeuses : incluez les projets abandonnés.
• L'IA peut produire des calculs faux avec assurance : vérifiez les ratios sur un échantillon.
• Ne présentez pas à un client un calcul de l'IA comme un engagement : c'est une aide à la décision.
• Ne transmettez pas d'historiques contenant des données confidentielles à un outil non autorisé.

Limites#

• La loi de Hofstadter n'est pas un biais cognitif au sens strict : c'est une loi empirique, formulée avec humour, qui synthétise une expérience commune. Elle n'a pas été établie par des expériences contrôlées et n'a pas de formulation chiffrée.
• Elle est irréfutable par construction : à toute estimation, quelle qu'elle soit, on peut dire qu'on y a déjà inclus la loi. Elle vaut comme mise en garde, pas comme prédiction testable.
• Elle ne s'applique pas à toute tâche : pour une activité répétitive, bien mesurée et peu incertaine, les estimations sont souvent justes. Elle vise les tâches complexes et nouvelles.
• Tous les projets ne dépassent pas : certains finissent en avance ou à l'heure ; ce sont les dépassements, plus marqués, qui tirent la moyenne.
• La « règle des 90-90 » et la « loi de Brooks » sont de la sagesse de métier, utiles mais non démontrées en laboratoire.

Sources et vérification#

• Hofstadter (1979), Gödel, Escher, Bach: An Eternal Golden Braid, Basic Books — énoncé de la loi ; prix Pulitzer 1980 (catégorie General Nonfiction).
• Simon & Newell (1958), « Heuristic Problem Solving: The Next Advance in Operations Research », Operations Research — les quatre prédictions de 1957.
• IBM, « Deep Blue » — match de mai 1997 contre Kasparov.
• Brooks (1975), The Mythical Man-Month, Addison-Wesley — optimisme des programmeurs, loi de Brooks.
• Bentley (1985), « Programming Pearls: Bumper-Sticker Computer Science », Communications of the ACM — la règle des 90-90, attribuée à Tom Cargill.
• Buehler, Griffin & Ross (1994), « Exploring the planning fallacy », Journal of Personality and Social Psychology — la base expérimentale du phénomène.
• Parkinson (1955), « Parkinson's Law », The Economist, 19 novembre 1955.

Voir aussi#