Comment prioriser un projet métier en retard : ce que j'ai appris en reconstruisant la confiance

Quand un projet possède beaucoup de retard, presque tout finit par devenir prioritaire.

Le métier attend plusieurs fonctionnalités. Certaines sont indispensables. D'autres sont attendues depuis longtemps. L'architecture pourrait être améliorée. Des workflows doivent être repris. Et pendant ce temps, il faut aussi montrer que le projet avance réellement.

Sur un projet que j'ai repris, cette question de priorisation est progressivement devenue aussi importante que le développement lui-même.

Avant le premier projet applicatif, les données étaient déjà gérées sur papier ou dans des fichiers Excel. Une première tentative de numérisation n'avait pas réussi à remplacer suffisamment ce fonctionnement, et l'application était finalement très peu utilisée.

La refonte ne partait donc pas seulement avec un problème technique.

Elle partait aussi avec un problème de confiance.

Il fallait reconstruire une application, reprendre les données existantes et répondre au besoin métier. Mais il fallait également donner suffisamment de résultats visibles pour que les utilisateurs aient de nouveau envie de participer au projet.

C'est dans ce contexte que j'ai appris qu'une priorité n'est pas forcément :

la fonctionnalité la plus importante sur la liste.

C'est parfois celle qui réduit le plus l'incertitude, débloque les étapes suivantes ou redonne suffisamment de confiance pour permettre au projet de continuer.

La première priorité était de rendre les données compréhensibles

Lors de la refonte, une partie importante du travail a consisté à reprendre les données existantes et à les importer dans une nouvelle base.

Ce travail a révélé quelque chose d'important : les données n'étaient pas nécessairement organisées de la même manière partout.

Certaines pratiques variaient selon les régions.

Construire un modèle plus cohérent ne servait donc pas uniquement à avoir une base de données plus agréable à manipuler côté développeur. Cela permettait aussi de faire converger les données vers une structure commune.

L'objectif était notamment que les informations puissent ensuite être transmises à une instance supérieure sans nécessiter une réécriture complète à chaque fois.

Cela m'a rappelé qu'un modèle de données n'est pas seulement une décision technique.

Il peut aussi devenir un point de rencontre entre plusieurs manières de travailler.

Mais construire une base cohérente ne suffisait pas.

Il fallait encore être certain que cette nouvelle représentation correspondait réellement à ce que le métier attendait.

L'une des premières fonctionnalités n'était pas spectaculaire : un export CSV

Une des premières fonctionnalités que j'ai développées pour le portail web était un export CSV des données.

D'un point de vue technique, ce n'était pas la partie la plus impressionnante du projet.

Mais elle répondait à une question beaucoup plus importante :

Est-ce que le métier reconnaît réellement ses données dans le nouveau système ?

Le format Excel était familier aux utilisateurs. Ils pouvaient donc regarder directement les colonnes, les valeurs et la manière dont les informations avaient été structurées.

Les discussions sont alors devenues beaucoup plus concrètes.

Certaines colonnes ont été ajoutées. Des demandes d'amélioration sont apparues. Des choix qui étaient difficiles à expliquer abstraitement sont devenus visibles.

L'export permettait aussi de donner une représentation claire des données à d'autres intervenants du projet.

Autrement dit, la fonctionnalité ne servait pas uniquement à télécharger un fichier.

Elle permettait de transformer une discussion théorique sur la base de données en quelque chose que tout le monde pouvait regarder.

Et surtout, elle réduisait une incertitude fondamentale :

Sommes-nous enfin d'accord sur les données que l'application doit manipuler ?

C'est probablement à ce moment-là que j'ai commencé à voir différemment la notion de MVP.

Un MVP ne doit pas seulement être petit, il doit réduire une incertitude

On définit souvent un MVP comme une première version avec peu de fonctionnalités.

Cette définition peut être utile, mais elle ne dit pas quelles fonctionnalités choisir.

Sur ce projet, mon objectif n'était pas simplement de produire l'application avec le moins de boutons possible.

Je cherchais surtout une première version capable de répondre rapidement aux questions les plus risquées.

Les données sont-elles correctes ?

Le métier comprend-il ce que nous construisons ?

Le workflow correspond-il réellement à sa manière de travailler ?

Pouvons-nous obtenir rapidement du feedback ?

Le portail web est donc devenu prioritaire parce qu'il permettait d'obtenir des réponses beaucoup plus vite.

Ce n'était pas nécessairement la partie finale du produit.

Mais c'était un excellent outil pour réduire l'incertitude.

La meilleure première fonctionnalité n'est pas toujours celle qui rapproche le plus visiblement de la version finale. Elle peut être celle qui évite de construire la mauvaise version finale.

Une fonctionnalité importante peut devoir attendre

L'export PDF en est un bon exemple.

Le métier le considérait comme utile et important.

Je ne contestais pas cette valeur.

Mais je pensais que stabiliser le workflow devait passer avant.

Construire un export final alors que les écrans, les champs ou les règles continuaient d'évoluer risquait simplement de créer davantage de travail.

Chaque modification du workflow aurait ensuite pu nécessiter de reprendre :

• les données exportées ;
• la présentation ;
• certaines règles ;
• éventuellement plusieurs variantes du document.

La question n'était donc pas :

L'export PDF est-il important ?

La réponse était oui.

La vraie question était :

Est-ce le bon moment pour investir dans cette fonctionnalité ?

Une fonctionnalité peut être prioritaire pour le métier tout en dépendant d'une autre décision qui doit être stabilisée avant.

C'est une nuance qui m'a beaucoup aidé ensuite.

La priorité n'est pas uniquement une mesure de valeur.

C'est aussi une question de dépendances.

Pour moi, un workflow était stable quand quelqu'un pouvait l'utiliser sans connaître l'application

Le projet concernait un outil métier qui n'était pas forcément utilisé tous les jours de l'année.

C'est une contrainte importante.

Un utilisateur peut très bien comprendre parfaitement un workflow lors d'une formation, puis revenir plusieurs mois plus tard en ayant oublié une partie de la procédure.

Je ne pouvais donc pas considérer qu'un workflow était bon uniquement parce qu'un utilisateur expérimenté arrivait à l'utiliser.

Mon critère est progressivement devenu plus exigeant :

Une personne qui connaît peu l'application doit pouvoir comprendre ce qu'elle doit faire sans se tromper facilement.

Cela change la manière de concevoir l'interface.

Il faut éviter de dépendre uniquement de la mémoire de l'utilisateur.

L'application doit porter elle-même une partie de la connaissance du processus.

Réduire volontairement les possibilités d'erreur

Une interface n'a pas toujours intérêt à offrir un maximum de liberté.

Dans certaines situations, plus de possibilités signifie simplement plus de manières de se tromper.

J'ai donc essayé de réduire les erreurs prévisibles lorsque le métier permettait de le faire.

Pour certaines saisies, par exemple, les caractères autorisés pouvaient être limités.

Lorsqu'un utilisateur ne devait choisir qu'entre quelques valeurs valides, il était préférable de l'empêcher d'en saisir une impossible plutôt que de compter sur sa vigilance.

Ce raisonnement dépasse la validation d'un champ.

Il concerne tout le workflow :

Que peut faire l'utilisateur ici ?
        ↓
Parmi ces actions,
lesquelles ont réellement du sens ?
        ↓
Pouvons-nous empêcher
les états incohérents ?
        ↓
Pouvons-nous guider l'utilisateur
vers le chemin attendu ?

Cela ne signifie pas qu'il faut enfermer l'utilisateur dans une interface rigide.

Mais lorsqu'une action est toujours incorrecte dans le métier, lui laisser cette possibilité ne crée pas réellement de valeur.

Un bon workflow ne se contente pas d'expliquer quoi faire. Il réduit aussi les occasions de faire quelque chose de faux.

Le métier m'a aussi appris que "logique" reste subjectif

Une application peut sembler parfaitement cohérente au développeur et beaucoup moins évidente pour la personne qui doit l'utiliser.

J'ai eu des retours du type :

Je ne comprends pas bien cette partie.

Ou :

Ce bloc devrait plutôt être placé ici.

Parfois, il manquait simplement un champ qui avait été oublié lors de la conception initiale.

Dans d'autres cas, l'ordre des blocs paraissait correct en réunion mais beaucoup moins naturel une fois l'application réellement utilisée.

Cette expérience m'a appris à ne pas répondre trop vite :

"Mais techniquement, ça fonctionne."

Dans une application métier, le comportement doit être techniquement correct, mais l'organisation de l'information reste aussi liée à la manière dont les utilisateurs travaillent réellement.

Une maquette peut être validée.

Puis l'utilisation sur tablette montre qu'un écran doit être réorganisé.

Ou l'usage réel révèle qu'une information qui semblait secondaire doit finalement être beaucoup plus visible.

Une maquette valide une intention. L'usage réel valide davantage le workflow.

Parfois, je commençais même par le front

Naturellement, j'ai longtemps eu tendance à raisonner backend d'abord.

Les données.

Les règles.

Puis l'interface.

Mais sur ce projet, il m'est arrivé de faire l'inverse pour certaines fonctionnalités.

Je pouvais construire la partie visuelle presque entièrement :

• les champs ;
• les blocs ;
• les boutons ;
• le parcours utilisateur.

Mais le bouton ne déclenchait encore aucune vraie action.

L'objectif n'était pas de faire semblant que la fonctionnalité était terminée.

L'objectif était de rendre le comportement visible suffisamment tôt pour pouvoir le challenger.

Le métier pouvait alors dire :

Ce champ manque.

Ou :

Ce bloc serait plus logique au-dessus.

Ou simplement :

Oui, c'est bien comme cela que nous voulons travailler.

Modifier une interface à ce moment-là coûtait relativement peu.

Faire la même découverte après avoir développé toute la logique, les validations et les interactions avec la base pouvait être beaucoup plus coûteux.

Ce n'est pas devenu ma règle absolue.

Je reste souvent plus naturellement orienté backend.

Mais j'ai appris que l'ordre de développement peut lui-même être un outil de réduction du risque.

Le visuel n'était pas aussi secondaire que je le pensais

J'avais aussi tendance à considérer certaines demandes esthétiques comme secondaires.

Après tout, il s'agissait d'une application métier.

Mon raisonnement initial pouvait facilement être :

Tant que le fonctionnement est correct, le reste peut attendre.

Avec le temps, j'ai changé d'avis.

Une interface plus soignée rendait immédiatement l'application plus crédible.

Et c'est logique.

L'utilisateur ne voit presque jamais directement la qualité de mon backend.

Il ne sait pas nécessairement si mon modèle de données est élégant, si une fonction est parfaitement découpée ou si mon architecture respecte un pattern particulier.

Ce qu'il perçoit du backend est surtout indirect :

• la page répond-elle rapidement ?
• la donnée affichée est-elle correcte ?
• l'action fonctionne-t-elle ?
• l'application semble-t-elle fiable ?

En revanche, l'interface est visible immédiatement.

Sa cohérence, son organisation et son apparence participent directement à la perception du produit.

Le backend construit une grande partie de la fiabilité de l'application. L'interface construit une grande partie de sa crédibilité auprès de l'utilisateur.

Sur un projet qui avait déjà connu une première tentative difficile, cette crédibilité avait une valeur particulière.

La confiance a changé lorsque le métier a vu le projet avancer

Au début, lorsque j'expliquais que le front pouvait changer rapidement et qu'il valait mieux parfois valider le workflow avant d'investir davantage dans le reste, le métier pouvait être sceptique.

L'explication restait abstraite.

Puis, après avoir validé davantage le fonctionnement, le portail web a beaucoup évolué visuellement en peu de temps.

La différence était immédiatement visible.

Le projet semblait soudain beaucoup plus concret.

C'est à ce moment-là que j'ai constaté une forte mobilisation du métier principal qui pilotait le projet.

Les échanges se sont multipliés.

Les demandes sont devenues plus précises.

Et surtout, j'ai senti beaucoup plus de confiance dans les choix techniques et dans la direction du projet.

Cela m'a appris quelque chose que je sous-estimais auparavant :

Sur un projet en difficulté, rendre le progrès visible peut avoir une vraie valeur technique indirecte.

Parce que davantage de confiance produit davantage de feedback.

Et davantage de feedback permet de prendre de meilleures décisions plus tôt.

Le mot "bug" ne veut pas toujours dire bug

Les échanges avec les utilisateurs m'ont aussi obligé à apprendre leur vocabulaire.

Le mot "bug" en est probablement le meilleur exemple.

Au début, recevoir un message disant :

Il y a un bug.

pouvait immédiatement me perturber.

Si j'étais en train de travailler sur une fonctionnalité complexe, je pouvais commencer à imaginer un problème grave : données incorrectes, comportement cassé, erreur en production.

Puis, en regardant réellement la demande, le "bug" pouvait être :

Ce bloc de texte devrait être au-dessus de l'autre.

Pour l'utilisateur, "bug" était parfois simplement un synonyme de :

J'ai un problème avec ce que je vois.

Ce n'est pas une mauvaise utilisation du langage qu'il faudrait absolument corriger.

C'est simplement un vocabulaire différent.

Le rôle du développeur est ensuite de déterminer ce qui se cache derrière.

"Il y a un bug"
        ↓
L'action échoue-t-elle ?
        ↓
La donnée est-elle fausse ?
        ↓
L'utilisateur est-il bloqué ?
        ↓
Le workflow est-il incompris ?
        ↓
Ou s'agit-il d'une amélioration ?

Comprendre cette différence m'a aussi permis de mieux protéger ma concentration.

Toutes les demandes ne doivent pas interrompre le travail en cours

Avec le temps, j'ai appris à ne plus laisser le mot utilisé dans un message décider automatiquement de l'urgence.

Un vrai problème urgent est pour moi beaucoup plus proche de situations comme :

• un incident en production ;
• un risque de corruption ou de perte de données ;
• un utilisateur réellement bloqué ;
• un problème suffisamment grave pour détruire la confiance dans l'application.

Le dernier critère est important.

Un comportement peut ne pas être catastrophique techniquement et pourtant être suffisamment visible pour donner l'impression que le système n'est pas fiable.

Dans ce cas, le corriger rapidement peut être pertinent.

À l'inverse, déplacer un bloc ou améliorer un écran peut parfaitement être utile sans justifier l'interruption immédiate d'un travail complexe.

Une urgence n'est pas ce qui est formulé avec le plus d'inquiétude. C'est ce qui menace réellement les données, l'usage ou la confiance dans le produit.

Cette distinction paraît évidente avec le recul.

Elle m'a pourtant demandé du temps.

Prioriser, c'est aussi comprendre comment le métier communique

Il y a une dimension plus humaine dans cette évolution.

Quand une demande arrivait et me paraissait mauvaise ou disproportionnée, ma première réaction n'était pas toujours parfaite.

Il pouvait m'arriver de râler seul dans mon bureau.

Mais cela avait aussi une utilité : une fois la première réaction passée, j'arrivais souvent à regarder le problème autrement.

Peut-être que le métier avait raison.

Peut-être que la demande était beaucoup plus simple à réaliser que je ne le pensais.

Peut-être qu'une autre solution existait.

Ou peut-être que mon objection initiale restait valable.

L'important était de ne pas transformer automatiquement ma première réaction en décision de projet.

Face au métier, il fallait être pédagogique.

Une modification qui semble simple depuis l'interface peut demander beaucoup de travail derrière.

Je pouvais donc expliquer :

• quelles parties du système seraient touchées ;
• pourquoi cela prendrait du temps ;
• quels risques apparaissaient ;
• ce qui devrait probablement passer après.

Je pouvais déconseiller une modification.

Mais si le métier comprenait le coût et considérait toujours la fonctionnalité comme importante, je n'avais pas besoin de gagner un débat.

Mon rôle était aussi de rendre le compromis visible.

Certaines demandes que je jugeais secondaires avaient réellement de la valeur

Les améliorations esthétiques en sont un bon exemple.

Je ne les aurais pas toujours placées très haut dans mes propres priorités.

Pourtant, une fois réalisées, certaines rendaient clairement l'application plus crédible et plus agréable.

Le métier percevait une valeur que je sous-estimais en raisonnant principalement comme développeur backend.

Cela m'a rappelé qu'une application métier reste un produit utilisé par des personnes.

Le développeur connaît la qualité interne du système.

L'utilisateur ne peut juger que ce qu'il expérimente.

Cela ne signifie pas que le métier doit décider de l'architecture ou de chaque détail technique.

Mais lorsque la question concerne réellement l'usage, son point de vue possède une importance particulière.

Mes critères de priorité sont progressivement devenus plus pragmatiques

Je n'ai jamais construit une formule permettant d'attribuer automatiquement une note à chaque tâche.

Ma manière de choisir repose plutôt sur plusieurs critères.

L'utilité

Qu'est-ce que cette tâche apporte réellement au métier ou au projet maintenant ?

La rapidité

Pouvons-nous obtenir rapidement un résultat utile ?

Une petite amélioration peut parfois valoir beaucoup si elle débloque immédiatement une discussion ou un usage.

Le contexte

Le projet est-il en train de chercher de la confiance, de stabiliser les données, de préparer une livraison ou de corriger un risque ?

La même fonctionnalité peut changer de priorité selon le moment.

Les dépendances

Est-il raisonnable de construire cette partie maintenant ou dépend-elle encore d'un workflow instable ?

Ma capacité à visualiser la modification

Je peux souvent estimer beaucoup plus facilement une tâche lorsque j'arrive déjà à comprendre :

• quelles données sont concernées ;
• quelles parties du code vont changer ;
• quelles fonctions seront impliquées ;
• quels problèmes peuvent apparaître ;
• combien de temps l'ensemble devrait demander.

Quand je n'arrive pas à visualiser une tâche, mon estimation devient naturellement beaucoup moins fiable.

Quand je ne peux plus visualiser mentalement, je schématise

Pour les fonctionnalités suffisamment complexes, je décompose le travail en blocs.

Je visualise souvent le programme comme une suite d'appels et de comportements :

Fonctionnalité
      ↓
Étape A
      ↓
Fonction
      ↓
Sous-fonction
      ↓
Décision
      ↓
Étape suivante

Je réfléchis étape par étape.

Et lorsque je n'arrive plus à garder correctement l'ensemble dans ma tête, je le couche sur papier.

Je dessine le flux.

Je représente les dépendances.

Je cherche l'endroit où quelque chose ne colle pas.

Je ne fais donc pas un schéma uniquement parce qu'un processus méthodologique me dit d'en faire un.

J'en fais un lorsque le problème dépasse ce que j'arrive à manipuler mentalement.

Le schéma devient alors une extension de ma mémoire de travail.

Et souvent, une fois le problème représenté, il devient également beaucoup plus simple à découper et à estimer.

Deux tâches de deux heures ne coûtent pas forcément la même chose

J'ai également appris à prendre en compte quelque chose que l'on voit rarement dans une liste de priorités : le niveau de concentration nécessaire.

Deux tâches peuvent être estimées à deux heures.

L'une peut être presque mécanique.

L'autre peut nécessiter deux heures continues pendant lesquelles il faut garder en tête plusieurs règles, plusieurs fichiers et plusieurs conséquences possibles.

Ces deux tâches ne sont pas équivalentes.

Je préfère généralement traiter les sujets complexes le matin, lorsque ma concentration est meilleure.

Après une réunion, il peut être plus difficile de replonger immédiatement dans un problème profond.

Une interruption pendant une tâche complexe peut aussi coûter beaucoup plus que les dix minutes de l'interruption elle-même.

Il faut reconstruire le contexte mental.

Retrouver les hypothèses.

Se rappeler ce que l'on allait modifier.

Parfois, cette perte de contexte peut perturber une grande partie de la matinée ou de l'après-midi.

Une interruption ne coûte pas seulement sa durée. Elle peut aussi coûter le contexte qu'il faut reconstruire ensuite.

Fatigue et fin de semaine font aussi partie de ma planification

J'ai appris à me méfier des modifications complexes lorsque je suis fatigué.

Même chose en fin de semaine.

Le vendredi, je préfère éviter de lancer certaines modifications importantes si elles peuvent raisonnablement attendre.

Pas parce que le vendredi possède une propriété technique particulière.

Simplement parce que j'ai déjà connu cette sensation désagréable de revenir sur mon code et de me demander :

Pourquoi ai-je compliqué quelque chose d'aussi simple ?

Lorsque la concentration baisse, une tâche qui semblait évidente peut devenir inutilement compliquée.

Aujourd'hui, je préfère donc garder certaines petites tâches pour ces moments-là et réserver autant que possible les sujets qui demandent beaucoup de raisonnement aux périodes où je peux réellement leur donner cette attention.

C'est une dimension très personnelle de l'organisation du travail.

Mais elle fait partie de mes estimations.

Planifier deux heures de développement ne consiste pas seulement à trouver deux cases vides dans un calendrier.

Il faut aussi que ces deux heures correspondent au type de travail demandé.

La priorité est aussi une question de confiance

Avec le recul, beaucoup de décisions prises sur ce projet peuvent être reliées à la même question.

Pourquoi commencer par rendre les données visibles ?

Pour vérifier qu'elles étaient comprises.

Pourquoi prioriser le portail web ?

Pour obtenir rapidement du feedback.

Pourquoi stabiliser le workflow avant certains exports ?

Pour éviter d'investir trop tôt dans quelque chose qui allait encore changer.

Pourquoi limiter certaines saisies ?

Pour réduire les erreurs utilisateur.

Pourquoi accorder davantage d'importance à l'esthétique que je ne l'aurais fait spontanément ?

Parce qu'elle participait à la crédibilité du nouvel outil.

Pourquoi ne plus paniquer à chaque message contenant le mot "bug" ?

Parce que toute inquiétude ne représente pas la même urgence.

Au départ, je pensais surtout la priorisation comme un classement :

1. Fonctionnalité A
2. Fonctionnalité B
3. Fonctionnalité C

Aujourd'hui, je la vois davantage comme une série de questions :

Qu'est-ce qui réduit le plus notre incertitude ?

Qu'est-ce qui débloque la suite ?

Qu'est-ce qui protège les données ?

Qu'est-ce qui améliore réellement l'usage ?

Qu'est-ce qui renforce ou menace la confiance ?

Qu'est-ce qui dépend encore d'une décision instable ?

Qu'est-ce que nous pouvons livrer rapidement ?

Quelle tâche demande un niveau de concentration
que je peux réellement lui donner maintenant ?

Le classement vient après.

La fonctionnalité la plus importante n'est pas toujours celle qu'il faut développer maintenant

Ce projet m'a appris qu'une bonne priorisation ne consiste pas uniquement à identifier les fonctionnalités importantes.

Presque tout peut être important lorsqu'un projet a accumulé beaucoup de retard.

La difficulté est de comprendre dans quel ordre cette valeur doit être construite.

Un export CSV assez simple peut devenir plus utile qu'une fonctionnalité beaucoup plus ambitieuse s'il permet de valider toute la structure des données.

Un portail web incomplet peut créer davantage de valeur immédiate qu'une application complète encore impossible à montrer.

Une amélioration visuelle peut être prioritaire lorsqu'elle participe à reconstruire la confiance.

Et une fonctionnalité considérée comme importante par tout le monde peut malgré tout attendre si elle dépend d'un workflow encore instable.

Je ne pense donc plus qu'une priorité soit uniquement :

ce que le métier veut le plus.

Ni :

ce que le développeur considère comme le plus important techniquement.

Elle se trouve quelque part entre les deux, en tenant compte du contexte, du risque, des dépendances, du coût et de ce que le projet doit apprendre maintenant.

Sur un projet en difficulté, la meilleure prochaine tâche est souvent celle qui réduit suffisamment l'incertitude ou le risque pour rendre la suivante plus évidente.

Et dans mon cas, le premier grand résultat de la refonte n'a probablement pas été une fonctionnalité particulière.

C'était d'avoir réussi, progressivement, à faire revenir le métier dans le projet.

Lorsque les utilisateurs ont recommencé à regarder les données, à proposer des améliorations, à valider le workflow et à faire confiance à la direction prise, le projet n'était pas encore terminé.

Mais il avait déjà récupéré quelque chose d'essentiel :

une boucle de confiance et de feedback suffisamment solide pour pouvoir continuer à construire.