Le jour où le problème a changé.

Tous les utilisateurs faisaient exactement la même chose. Ils téléchargeaient le document. L’ouvraient dans Word. Passaient la page du format portrait au format paysage. Puis reprenaient leur travail.

Personne ne leur avait expliqué cette manipulation. Avec le temps, elle était simplement devenue normale.

Le document contenait un grand tableau. L’aperçu en ligne était parfaitement lisible, mais une fois téléchargé, une partie des colonnes disparaissait hors de la page. Changer l’orientation faisait désormais partie de la procédure.

On ne parlait plus vraiment d’un problème. On parlait d’une habitude.

Ce n’est que bien plus tard que j’ai appris que ce sujet revenait depuis des années. Sans jamais être développé.

Évolution du problème

Étape	Ce qui s’est passé
Symptôme	Les utilisateurs passaient systématiquement le document en paysage avant de pouvoir le lire.
Hypothèse initiale	L’aperçu devait rester en portrait, l’export devait donc utiliser une autre mise en page.
Découverte	Les utilisateurs ne demandaient pas deux mises en page. Ils voulaient simplement lire leur document.
Reformulation	Utiliser la même mise en page en paysage pour l’aperçu et l’export.

Ce qui m’a le plus surpris n’était pas le problème. C’était la façon dont tout le monde le décrivait.

Pendant des années, la discussion tournait autour de la même question :

Comment garder un aperçu en portrait tout en générant un document en paysage ?

À partir du moment où cette hypothèse devenait évidente, le reste suivait naturellement. Deux mises en page. Deux comportements. Deux implémentations.

Le problème paraissait de plus en plus complexe.

Puis le Product Owner m’a transmis ce retour utilisateur. Avant de parler de solution, nous avons simplement reformulé la question.

Quel est le vrai problème de l’utilisateur ?

La réponse était presque décevante de simplicité. Les utilisateurs ne demandaient pas deux affichages différents. Ils voulaient ouvrir le document… et pouvoir le lire.

Si le format paysage est celui qui fonctionne le mieux, pourquoi conserver le portrait dans l’aperçu ? Personne ne semblait vraiment se souvenir de l’origine de cette contrainte.

Une fois la décision prise, le développement a été très rapide. Je suis allé voir le développeur. Je lui ai demandé combien de temps il avait réellement passé à modifier le code.

Il m’a répondu :

Une minute, à peu près.

Puis il a ajouté, presque en riant :

La minute n’est pas le plus long.

Il fallait créer une Feature. Créer une branche. Fusionner le code. Résoudre les conflits. Préparer les tests. Les exécuter. Valider le résultat. Publier.

La modification elle-même représentait la partie la plus courte de toute la chaîne.

Avant de partir, il m’a dit une dernière chose.

En réalité, personne n’avait vraiment analysé ce sujet.

Ce n’était jamais prioritaire.

Et nous pensions tous que ce serait compliqué.

Ce que j’en retiens

Cette minute n’a jamais été la partie la plus chère de cette histoire. Le véritable coût s’était accumulé bien avant.

Pendant des années, chacun avait accepté une contrainte dont plus personne ne questionnait l’origine. Les utilisateurs tournaient leurs documents. Les équipes imaginaient des solutions complexes. Le code, lui, attendait simplement que la bonne question soit enfin posée.