Loi de Hofstadter: pourquoi vos plannings glissent toujours

Douglas Hofstadter a formulé sa loi en 1979 dans « Gödel, Escher, Bach », et tout porteur de projet la vit encore : ça prend toujours plus de temps que prévu, même quand on a prévu que ça prendrait plus de temps. Près d’un demi-siècle plus tard, elle reste la loi la mieux vérifiée du développement logiciel. La comprendre change concrètement la façon de mener un projet, et surtout la façon d’en acheter un.

Que dit exactement la loi de Hofstadter ?

La formulation originale tient en une phrase : « il faut toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter ». Sa structure récursive est tout sauf un gag : elle dit que le dépassement survit à sa propre anticipation. Vous estimez trois mois, vous ajoutez un mois de marge par prudence, le projet en prend six. Le problème n’est ni votre sérieux ni celui de votre prestataire : c’est la structure même de l’exercice d’estimation.

Estimer un projet logiciel, c’est prédire le comportement d’un système qu’on n’a pas encore construit, intégré à des systèmes qu’on ne connaît pas encore, utilisé par des gens qu’on n’a pas encore observés. L’information nécessaire à une bonne estimation n’existe tout simplement pas au moment où on la demande : elle se fabrique en avançant.

Pourquoi les plannings glissent : les trois mécaniques

La complexité est cachée par construction. Les 80 % visibles d’une fonctionnalité se développent vite ; les 20 % restants (cas limites, gestion d’erreurs, données sales, interfaçage qui ne respecte pas sa propre documentation) consomment l’essentiel du temps. On ne les découvre qu’en creusant : aucune spécification préalable ne les liste tous, et un cahier des charges exhaustif donne seulement l’illusion du contraire.

L’optimisme est structurel. Celui qui estime se représente le scénario où tout se passe bien, parce que c’est le seul qu’il peut se représenter en détail. Les imprévus, par définition, ne figurent pas dans le plan. Ce biais ne se corrige pas par la bonne volonté : il se corrige par la méthode.

L’effet tunnel amplifie tout. L’effet tunnel désigne une longue période de développement sans confrontation au réel : pas de livraison, pas de démo, pas d’utilisateurs. Les petites dérives s’y accumulent en silence et se révèlent d’un coup, trop tard pour être absorbées. Six mois de tunnel, c’est six mois de dérives composées.

Comment composer avec, au lieu de lutter contre ?

Toute notre méthode découle de ce constat, en trois principes appliqués à chaque projet.

1. Estimer court, chiffrer ferme. Une V1 au périmètre serré, cadrée en une à deux semaines de discovery, se chiffre et se date de façon fiable : c’est l’engagement que nous prenons, par écrit. Ce qui dépasse l’horizon de la V1 reste un backlog priorisé, pas une promesse datée. Promettre au-delà de ce qu’on peut estimer, c’est mentir poliment, et le marché du développement logiciel vit largement de ce mensonge.

2. Couper, et le dire. Le périmètre est la seule variable d’ajustement saine d’un projet : le budget et la qualité n’en sont pas, et la date encore moins. Quand un imprévu surgit (il surgira), la question n’est pas « comment tenir quand même ? » mais « qu’est-ce qui sort de la V1 pour que la date tienne ? ». Un cadrage honnête prépare cette conversation dès le premier jour, avec des non-objectifs explicites et un backlog déjà priorisé pour l’arbitrage.

3. Livrer toutes les une à deux semaines. Chaque livraison est un point de contact avec le réel : le glissement se mesure en jours et se corrige en heures, au lieu de se découvrir en mois. C’est la différence entre piloter et espérer. Sur nos projets, la première version testable arrive en général avant la fin du premier mois, et une release suit chaque semaine ensuite.

Ce que ça change quand vous achetez un développement

Si vous faites développer un logiciel, la loi de Hofstadter vous donne trois questions à poser avant de signer, et les réponses valent tous les portfolios :

1. Le périmètre chiffré est-il assez court pour être estimable ? Un engagement ferme sur six semaines est crédible ; sur dix-huit mois, c’est une fiction.
2. Que se passe-t-il quand un imprévu surgit ? La bonne réponse décrit un arbitrage de périmètre, pas un processus d’avenants.
3. À quelle fréquence verrai-je le logiciel fonctionner ? La bonne réponse se compte en semaines, pas en jalons trimestriels.

Les réponses distinguent immédiatement ceux qui ont compris la loi de ceux qui la subiront avec votre budget. Si vous voulez voir à quoi ressemble un planning qui tient (et ce qu’on coupe pour qu’il tienne), venez nous en parler : 30 minutes suffisent pour cadrer votre projet avec des dates qu’on pourra regarder en face.