Prévision du Taux d'Arrivée au Backlog

Bon, l'idée c'est simple. Tu prends tes données historiques — combien de tickets sont arrivés chaque mois — et l'outil en tire deux choses. D'abord, la tendance : est-ce que la demande monte, descend, ou stagne ? Ensuite, la saisonnalité : est-ce qu'il y à des mois qui reviennent toujours plus forts ou plus faibles ? Avec ces deux composantes, il génère une prévision pour les mois à venir. Mais attention, c'est pas de la magie. C'est des maths — régression linéaire et décomposition saisonnière. Du coup, la qualité de la prévision dépend directement de la qualité de tes données. Si tes chiffres sont cohérents et que t'en as assez, la prévision sera solide. Sinon, le R² te le dira clairement. C'est quand même mieux que de deviner au doigt mouillé comme la plupart des équipes font, non ?

J'ai vu tellement d'équipes fonctionner en mode pompier. Un mois tranquille, le mois suivant 40 tickets tombent d'un coup, tout le monde panique, le WIP explose, les temps de cycle doublent, et on finit par livrer en retard avec de la dette technique plein les bras. Ça te parle ? Le problème c'est pas la demande. Le problème c'est qu'on ne l'anticipe pas. Avec une prévision fiable, tu peux planifier les embauches à l'avance (parce que recruter un dev ça prend 3 mois minimum). Tu peux négocier les engagements avec le business sur une basé factuelle au lieu de dire "on fera de notre mieux". Tu peux anticiper les pics saisonniers et réduire le périmètre proactivement. Et surtout, tu peux montrer aux stakeholders, chiffres à l'appui, pourquoi tu as besoin de plus de capacité. C'est dur de dire non à des données.

Deux métriques, c'est tout ce qu'il te faut pour savoir si ta prévision vaut quelque chose. Le MAE — Mean Absolute Error — te dit en moyenne de combien la prévision se trompe. Un MAE de 5 sur un backlog qui reçoit 100 tickets par mois, c'est excellent. Un MAE de 5 sur un backlog de 10 tickets par mois, c'est catastrophique. Le contexte compte. Le R², c'est la proportion de la variation que le modèle capture. Un R² de 0.85, ça veut dire que 85% du comportement de tes données est expliqué. Les 15% restants, c'est du bruit, des événements ponctuels. En pratique, au-dessus de 0.7 c'est bien. En dessous de 0.5, y'a un souci — soit pas assez de données, soit des anomalies qui faussent tout. Et dans ce cas, l'outil te le dit clairement. Pas besoin d'être data scientist pour interpréter ça.

Premier truc : sois cohérent dans ta collecte. Si tu comptes les user stories un mois et les sous-tâches le mois suivant, ta prévision sera n'importe quoi. Définis ce qu'est un élément de backlog et mesure toujours la même chose. Deuxième truc : vire les anomalies. Ce mois où tu as importé 200 tickets d'un ancien système ? Exclue-le. Sinon le modèle croit que c'est normal et ta prévision sera gonflée. Troisième truc : vise 12 à 24 points de données pour la saisonnalité. Avec 6 points tu peux dégager une tendance, mais les patterns cycliques ont besoin de plus de recul. Et quatrième truc, le plus important : compare ta prévision avec la réalité chaque mois. Le mois dernier tu avais prévu 28, t'en as eu 32 ? Note-le, intègre le nouveau point, et recalcule. C'est comme ça que ta prévision s'améliore avec le temps. Combine le tout avec tes métriques de temps de cycle et de débit et tu as une vue complète demande vs. capacité.