La méthode CURSE : enfin bien estimer une tâche

"Ça prend combien de temps ?" C'est la question qu'on redoute le plus, parce qu'on y répond presque toujours avec un seul chiffre — et ce chiffre est presque toujours faux.

Le problème n'est pas qu'on estime mal. C'est qu'on essaie de faire tenir cinq questions différentes dans une seule réponse. Une tâche peut être simple à coder mais pleine d'inconnues techniques. Une autre peut être triviale techniquement mais dangereuse pour le système en place. CURSE, c'est la grille qui sépare ces questions au lieu de les mélanger.

D'où vient CURSE

L'acronyme a été popularisé dans le monde Scrum par Lennie Noiles et Bill DeVoe (Artemis Agile), à l'origine pour affiner le story pointing en équipe. Mais la grille dépasse largement le contexte agile : elle marche aussi bien pour chiffrer un devis client, planifier un sprint solo ou juste répondre honnêtement à "ça prend combien de temps ?" en réunion.

CURSE veut dire Complexity, Uncertainty, Risk, Scope, Effort — en français : Complexité, Incertitude, Risque, Périmètre, Effort.

On n'estime jamais "une tâche" — on estime cinq choses différentes qui portent le même nom.

Complexité — à quel point c'est difficile à concevoir

La complexité mesure la difficulté intrinsèque du problème : combien de composants interagissent, combien de cas particuliers à gérer, combien de logique métier à orchestrer.

Une tâche peut être longue sans être complexe — copier 200 lignes de configuration prend du temps, mais ne demande aucune réflexion. À l'inverse, un algorithme de dix lignes peut être redoutablement complexe s'il doit gérer une dizaine de cas limites en parallèle.

Incertitude — ce qu'on ne sait pas encore

L'incertitude, c'est tout ce que l'équipe n'a jamais fait, ou ne maîtrise pas encore : une nouvelle librairie, une API tierce mal documentée, une partie du code jamais touchée.

C'est l'axe le plus souvent oublié — et le plus dangereux. Une tâche "simple" avec une forte incertitude peut exploser en durée dès qu'on découvre, en cours de route, que le problème n'était pas celui qu'on croyait.

Complexité et incertitude se confondent souvent, mais elles appellent des réponses différentes : la complexité se planifie, l'incertitude se réduit — par un spike, un prototype, une recherche préalable.

Risque — ce que ça peut casser

Le risque évalue l'impact si les choses tournent mal : une modification sur le système de paiement n'a pas le même poids qu'un changement de couleur sur un bouton, même si les deux prennent le même temps à coder.

Une tâche à faible risque peut être livrée vite, testée en prod, corrigée si besoin. Une tâche à haut risque demande plus de tests, une revue plus attentive, parfois un déploiement progressif — et ce temps de précaution fait partie de l'estimation, pas un supplément qu'on découvre après coup.

Périmètre — jusqu'où ça va

Le périmètre, c'est l'étendue du changement : combien de fichiers, de modules, d'équipes ou de systèmes sont touchés.

Une modification "small" en apparence peut avoir un périmètre énorme si elle touche vingt endroits du code, tandis qu'une fonctionnalité qui semble ambitieuse peut être confinée à un seul module bien isolé. Sans cet axe, on confond souvent "gros visuellement pour le client" et "gros à réaliser".

Effort — le travail réel

L'effort, c'est ce que l'on associe spontanément à une estimation : le temps de frappe, de configuration, de tests, une fois que la complexité est comprise, l'incertitude levée et le risque cadré.

C'est volontairement le dernier axe de la grille, pas le premier : estimer l'effort avant d'avoir qualifié les quatre autres, c'est estimer à l'aveugle.

Comment l'utiliser concrètement

CURSE n'est pas une formule qui recrache un chiffre — c'est un support de conversation. Sur chaque tâche, l'équipe (ou toi, seul face à un devis) passe les cinq lettres en revue et note, même approximativement, où elle se situe sur chacune :

Axe	Question à se poser
Complexité	Combien de logique, de cas limites, d'interactions ?
Incertitude	Qu'est-ce qu'on n'a jamais fait ou jamais vu ?
Risque	Qu'est-ce qui casse si ça se passe mal ?
Périmètre	Combien d'endroits, de systèmes, de personnes sont touchés ?
Effort	Une fois tout ça clarifié, combien de temps de travail pur ?

Une tâche haute en incertitude et basse en effort mérite un spike avant d'être chiffrée. Une tâche haute en risque et basse en complexité mérite plus de tests, pas plus de développement. Le chiffre final reste un chiffre unique si besoin — mais il est désormais justifié par cinq réponses au lieu d'une intuition.

Conclusion

La plupart des dérapages de planning ne viennent pas d'un mauvais calcul de l'effort — ils viennent d'une incertitude ou d'un risque qu'on n'avait jamais nommés. CURSE ne rend pas les estimations parfaites, mais il oblige à se poser les bonnes questions avant de sortir un chiffre, et ça change tout sur la fiabilité d'un planning.

La prochaine fois qu'on te demande "ça prend combien de temps ?", passe la tâche à la moulinette des cinq lettres avant de répondre. Tu répondras peut-être toujours avec un seul chiffre — mais ce sera le bon.