Schéma : un outil métier entouré de messages, de mails et de notes, dont les données partent en export vers un tableur puis reviennent en ressaisie.

UX design 7 min de lecture

Contournements d'un outil métier : ce qu'ils vous disent

Un tableur parallèle décrit mieux le travail réel qu'un cahier des charges. Voici comment nous lisons les contournements avant de bâtir un outil.

Par Gabrielle Tanneau, Product Manager & Product Design Publié le

Sommaire
  1. À quoi ressemble un contournement
  2. Pourquoi un contournement dit plus vrai qu’un audit
  3. Comment nous recensons les contournements
  4. Trois lectures possibles d’un même contournement
  5. L’erreur fréquente : supprimer le contournement
  6. Un exemple : trois applications de supervision routière
  7. Quand recenser les contournements ne suffit pas
  8. Ce que le recensement des contournements change dans un projet

Un contournement est la trace la plus fiable d’un besoin que votre outil ne couvre pas. Un tableur tenu à côté du logiciel, un groupe de messagerie d’équipe, un mail récapitulatif envoyé chaque vendredi : chacun compense un manque précis. Avant toute refonte ou tout nouvel outil interne, nous commençons par les recenser, parce qu’ils décrivent le travail réel mieux qu’un cahier des charges.

À quoi ressemble un contournement

Un contournement est une action répétée, faite en dehors de l’outil officiel, pour compenser ce que cet outil ne permet pas. Il est presque toujours visible, et presque jamais documenté.

Une scène revient souvent dans nos ateliers de cadrage. Le service logistique dispose d’un progiciel de gestion intégré (ERP), le logiciel qui centralise commandes, stocks et facturation. Chaque soir, la responsable recopie pourtant les statuts d’expédition dans un tableur partagé, auquel elle a ajouté une colonne « vraie date de départ ». Toute l’équipe consulte ce tableur. Personne n’ouvre l’écran prévu pour cela dans l’ERP.

Ce fichier dit trois choses : l’information juste n’est pas dans l’outil, quelqu’un la connaît, et l’équipe a décidé de lui faire confiance plutôt qu’au logiciel.

Contournement observéCe qu’il compenseLa question que nous posons
Un tableur recopié depuis le logicielUne donnée absente ou fausse dans l’outilQuelle information manque, et qui la détient ?
Un groupe de messagerie d’équipeAucune alerte ni statut partagéÀ quel moment l’équipe doit-elle être prévenue ?
Un mail récapitulatif hebdomadaireAucune vue d’ensembleQuelle décision ce mail permet-il de prendre ?
Un cahier ou des notes près du posteUne saisie trop longue ou une étape trop lenteCombien de fois par jour cette saisie est-elle faite ?
Une personne qui « sait faire »Une règle jamais formaliséeQue se passe-t-il pendant ses congés ?

Pourquoi un contournement dit plus vrai qu’un audit

Un contournement montre l’outil tel qu’il est vécu, quand un audit d’ergonomie évalue l’outil tel qu’il a été conçu. Les deux sont utiles, mais seul le premier révèle les besoins que personne n’a écrits.

L’audit heuristique est l’évaluation d’une interface par un expert, à partir de principes d’ergonomie établis : cohérence, lisibilité, prévention des erreurs. Il repère des défauts d’écran. Il ne voit pas qu’une équipe entière travaille dans un autre fichier.

Personne ne maintient un doublon par plaisir. Recopier des statuts chaque soir prend du temps, et ce temps est le prix que l’équipe accepte de payer pour avoir une information juste. Le contournement mesure donc l’importance du besoin.

En entretien, les utilisateurs minimisent souvent leurs difficultés, par habitude ou par loyauté envers l’outil choisi par l’entreprise. Leurs fichiers, eux, ne minimisent rien.

Un contournement durable signale enfin une perte de confiance. L’équipe a cessé d’attendre une amélioration de l’outil officiel et s’est organisée sans lui. Ce signal touche à l’adoption même de l’outil, bien au-delà d’un défaut d’ergonomie.

Comment nous recensons les contournements

Nous observons le travail au poste avant d’interroger, puis nous comptons. La méthode tient en cinq étapes, menées pendant le cadrage.

  1. Observer une journée de travail réel. Au poste, avec les vraies tâches, et pas une démonstration de l’outil.
  2. Poser une question simple. « Qu’est-ce qui vous fait perdre du temps tous les jours ? » Les réponses mènent directement aux fichiers et aux canaux parallèles.
  3. Inventorier les doublons. Chaque fichier, canal ou document qui reproduit une fonction de l’outil est listé, avec sa fréquence d’usage et le nombre de personnes qui en dépendent.
  4. Qualifier chaque contournement. Il relève de l’ergonomie, d’une donnée manquante ou d’un process qui a changé (voir le tableau suivant).
  5. Valider avec un référent métier. Une personne de l’équipe, qui connaît le travail réel, confirme la liste et l’ordre de priorité.

Trois lectures possibles d’un même contournement

Un contournement ne mène pas toujours au même chantier. La réponse dépend du manque qu’il compense, et c’est ce diagnostic qui évite de refaire un écran qui n’était pas en cause.

Ce que révèle le contournementLe signeLa réponse adaptée
Un défaut d’ergonomieL’information existe dans l’outil, mais elle est trop longue à trouverUne refonte ciblée des écrans concernés
Une donnée ou une étape manquanteL’outil ne connaît pas l’information que l’équipe utiliseFaire évoluer l’outil, ou le connecter à la bonne source
Un process qui a changéLe contournement est devenu le processUn outil conçu sur le travail réel, souvent sur-mesure

La troisième lecture appelle une décision plus lourde. Quand un logiciel du marché couvre l’essentiel de votre besoin, nous vous le disons, et nous proposons de le configurer plutôt que de le remplacer. Quand l’écart entre l’outil et votre process est devenu structurel, le coût des contournements, payé chaque jour en saisies doubles et en relances, justifie de construire un outil qui vous appartient.

Innovation Sprint · 5 jours

« Je ne sais pas encore si mon idée tient devant de vrais utilisateurs. »

Nous validons votre idée avant que vous n'engagiez le développement.

Découvrir l'offre
  • Design Sprint de cinq jours
  • Prototype haute fidélité
  • Tests avec de vrais utilisateurs
  • Rapport de validation et recommandations

L’erreur fréquente : supprimer le contournement

Interdire le tableur parallèle sans comprendre ce qu’il compense produit un nouveau contournement, moins visible que le premier. C’est l’erreur que nous observons le plus souvent après un déploiement imposé.

Un contournement contient souvent une bonne idée. La colonne « vraie date de départ » de notre exemple logistique devient, dans l’outil cible, un champ saisi au bon moment par la bonne personne. Le fichier disparaît parce qu’il ne sert plus, et non parce qu’il a été interdit.

Nous traitons donc chaque contournement comme de la matière de cadrage. Il dit ce que l’outil doit faire, mais aussi comment l’équipe a appris à le faire sans lui.

Un exemple : trois applications de supervision routière

Moderniser un outil utilisé par des experts commence par respecter ce que leurs habitudes savent faire. Un opérateur de supervision du trafic routier travaille avec trois applications métier critiques, en service depuis 30 ans : une main courante, un synoptique cartographique et un référentiel.

Les opérateurs y travaillent en poste prolongé, face à une forte densité d’informations, avec des décisions à prendre vite et un risque d’erreur élevé. En trente ans, ils ont construit leurs réflexes autour de ces écrans. Une interface plus moderne, mais étrangère à ces réflexes, aurait recréé des contournements dès la mise en service.

La refonte a donc traité ces habitudes comme une exigence de conception. Les trois applications partagent désormais un design system commun (une bibliothèque de composants et de règles graphiques réutilisables), avec des états explicites pour chaque situation : normal, crise, erreur, verrouillé. Les situations de crise ont leur propre traitement visuel, avec une hiérarchie, des contrastes et des résumés pensés pour décider vite. Le déploiement s’est fait par étapes, sans interrompre l’activité.

Quand recenser les contournements ne suffit pas

Recenser les contournements ne donne pas la bonne réponse dans trois situations, et nous le disons au cadrage, avant le devis.

Quand le contournement répond à une contrainte externe. Un double archivage exigé par la réglementation, ou un client qui impose son propre portail, ne signale pas un défaut de votre outil. Le supprimer serait une erreur.

Quand il est porté par une seule personne. Un fichier tenu par une personne, que personne d’autre ne consulte, relève parfois d’une préférence de travail. Le nombre de personnes qui en dépendent fait la différence entre un signal et une habitude.

Quand le process lui-même n’est pas stabilisé. Si chaque équipe travaille différemment, les contournements reflètent cette instabilité. Construire un outil à ce stade revient à figer un process qui n’est pas encore décidé : il faut d’abord le stabiliser.

Ce que le recensement des contournements change dans un projet

Un projet qui part des contournements démarre avec une liste de besoins observés et priorisés par leur fréquence. Il évite de traiter une liste de non-conformités qui ne dit rien de l’usage.

Cette liste sert ensuite de critère de réussite : une première version en service est utile quand les fichiers parallèles qu’elle devait remplacer ne sont plus ouverts.

Pour aller plus loin, notre page concevoir l’outil métier que vos équipes utilisent vraiment détaille la démarche, du cadrage à la mise en service. Si vos contournements concernent surtout des saisies répétées entre plusieurs logiciels, la page automatiser les tâches répétitives de vos équipes présente les options. Et si le contournement révèle un produit à repenser dans son ensemble, la page structurer un produit explique par où commencer.

Écrit par

Gabrielle Tanneau

Co-fondatrice de Pégase Digital, directrice produit

Découvrir l'équipe Suivre Gabrielle sur LinkedIn (nouvel onglet)

Un projet en tête ?
Parlons-en

Planifier un échange