« Ça fonctionne pareil » : la phrase qui cache une variante non documentée

La phrase qui clôt une question trop vite

Un cadrage de processus avance bien jusqu'à ce qu'une question un peu insistante tombe sur une réponse trop rapide : « non, ça fonctionne pareil avec tout le monde ». La question portait sur la manière dont une entreprise traite ses différents interlocuteurs externes, plusieurs gestionnaires de réseau, plusieurs partenaires, plusieurs administrations, chacun avec sa propre plateforme. La réponse ferme la discussion en une phrase. Le consultant note « pareil pour tous » dans son compte-rendu, et le cadrage continue.

Ce réflexe n'a rien d'isolé. Il se répète à chaque fois qu'un processus implique plusieurs interlocuteurs, plusieurs sites, ou plusieurs types de clients : la personne interrogée répond sur l'intention du processus, pas sur son exécution réelle case par cas. Le problème n'apparaît pas tout de suite. Il apparaît quand l'outil censé automatiser ce processus rencontre le premier cas qui, justement, ne fonctionnait pas pareil.

Le compte-rendu qui note « pareil pour tous » n'est pas un mauvais compte-rendu, il retranscrit fidèlement ce qui a été dit. C'est justement le problème : une phrase exacte au moment où elle est prononcée peut devenir fausse dès qu'on la transforme en spécification. Le cadrage avance sur une fondation qui semblait solide, et personne n'a menti pour autant. La faille n'est pas dans la sincérité de la réponse, elle est dans la question qui l'a appelée.

Pourquoi « pareil » est presque toujours une approximation

Une personne qui traite un processus au quotidien ne le décrit jamais tâche par tâche, elle le décrit par son résultat. Demandez-lui comment elle gère trois clients différents, elle répondra qu'elle « facture » ou qu'elle « transmet le dossier », parce que c'est ce résultat qui compte dans sa tête. Les différences de formulaire, de délai, de plateforme ou d'interlocuteur qu'elle traverse pour y arriver ont depuis longtemps disparu de sa description consciente : elle les a automatisées elle-même, dans sa propre routine, sans jamais les nommer.

Ce qui se cache derrière une affirmation d'uniformité

Cette généralisation n'est pas de la mauvaise foi, c'est un raccourci cognitif normal. Le problème, c'est que ce raccourci fonctionne exactement à l'inverse de ce dont un projet de cadrage a besoin. Un logiciel n'exécute jamais « le résultat  », il exécute chaque étape, avec ses branches et ses cas particuliers. Ce que la personne a oublié de mentionner parce que c'est devenu automatique pour elle devient, pour l'outil, la première chose qui doit être explicitement codée.

Le risque grossit avec le nombre d'interlocuteurs externes du processus. Plus il y a de gestionnaires de réseau, de partenaires ou d'administrations impliqués, plus la probabilité qu'au moins un fonctionne différemment des autres augmente, et plus l'affirmation « pareil pour tous » devient statistiquement fragile, même si elle part d'une intention honnête.

Ce que ça coûte quand la variante sort après coup

Une variante non documentée ne disparaît jamais, elle change seulement de moment d'apparition. Découverte pendant le cadrage, elle coûte une question de plus et une ligne dans un tableau de spécifications. Découverte après la mise en production, elle coûte une reprise de code sur un système déjà utilisé, avec des données déjà engagées dans le mauvais parcours et des utilisateurs qui ont, entre-temps, appris à contourner l'outil pour le cas qu'il ne gère pas. Le montant ne change pas de nature, il change d'ordre de grandeur.

Ce décalage explique pourquoi la variante non détectée reste si peu visible en amont : son coût réel n'apparaît jamais sur le budget de cadrage, il apparaît trois ou quatre mois plus tard, sur une ligne de correctif que personne ne relie plus à la question mal posée qui l'a précédée.

Presque pareil : la question qui force la variante à sortir

Chez Leando, ce principe s'appelle presque pareil : ne jamais accepter au mot une affirmation de similarité totale entre deux cas métier, et chercher systématiquement ce qui diffère avant de les fusionner dans le même parcours logiciel. La méthode ne consiste pas à remettre en cause la bonne foi de l'interlocuteur, elle consiste à déplacer la question du résultat vers le mécanisme. Au lieu de demander si ça fonctionne pareil, on demande quelles informations sont différentes, quels formulaires sont différents, quels délais sont différents.

Les trois questions qui remplacent « est-ce que ça marche pareil »

Trois questions suffisent la plupart du temps à faire émerger une variante restée invisible. Quelles informations demande-t-on dans un cas et pas dans l'autre ? Par quel canal ou quel formulaire chaque cas transite-t-il ? Et quel délai sépare la demande de sa réponse dans chaque cas ? Ces trois questions portent sur le mécanisme, jamais sur l'intention, ce qui les rend beaucoup plus difficiles à balayer d'un «  pareil » général.

La différence tient à ce que chaque question réclame une réponse concrète et vérifiable, pas une impression générale. Il est facile de répondre « oui, pareil » à une question sur le principe. Il est beaucoup plus difficile de répondre « oui, identique » quand on vous demande de citer les trois champs d'un formulaire, et c'est précisément cette difficulté qui fait remonter l'information utile : soit la personne confirme, avec des exemples précis à l'appui, soit elle hésite, et l'hésitation elle-même est un signal à noter.

« Je trouve que sur le Publipostage 2.0, on n'a pas été assez proche de ce que vous viviez vraiment au quotidien, et du coup, on a manqué de certains scénarios. »

Ce constat résume la cause profonde du problème : une variante manquée n'est presque jamais un manque de compétence technique, c'est un manque de proximité avec le quotidien réel de la personne qui exécute le processus. Plus le cadrage reste à distance de ce quotidien, plus il se contente de la version résumée que l'interlocuteur en donne, et plus les scénarios rares restent invisibles jusqu'à la mise en production.

Ce que ça exclut

Presque pareil ne veut pas dire chercher une exception sur chaque détail d'un processus. Un projet qui interroge chaque tâche avec la même intensité n'avance plus du tout, et beaucoup de variantes réelles n'ont aucune conséquence sur l'outil à construire. Le principe se réserve aux points de jonction avec un tiers externe, un gestionnaire de réseau, un partenaire, une administration, parce que c'est précisément là que la probabilité d'une variante non mentionnée est la plus élevée. Sur une tâche interne exécutée par la même équipe du début à la fin, l'affirmation de similarité mérite en général d'être prise pour argent comptant.

Le principe exclut aussi de traiter chaque variante trouvée comme une urgence à corriger dans l'instant. Une fois identifiée, elle rejoint la liste des arbitrages à trancher pendant la conception : certaines variantes justifient une branche dédiée dans l'outil, d'autres se traitent très bien par une exception gérée manuellement si elles ne concernent qu'un cas sur cinquante. L'objectif n'est pas de tout automatiser dès le premier jour, c'est de savoir que la variante existe avant de décider, en connaissance de cause, de la reporter ou non.

Pour approfondir la manière de documenter ce que ces variantes révèlent une fois identifiées, notre article sur les règles métier implicites détaille comment les faire remonter avant qu'elles n'explosent en cours de développement.

Un fournisseur d'énergie et ses gestionnaires de réseau

Un fournisseur d'énergie ETI, filiale d'un groupe suisse, cartographiait son processus de raccordement avec plusieurs gestionnaires de réseau régionaux. L'équipe interne assurait que le traitement était identique d'un gestionnaire à l'autre : une demande, un délai, une réponse. En creusant avec les trois questions du mécanisme, il est apparu que chaque gestionnaire disposait de sa propre plateforme, de ses propres formulaires, et transmettait des informations différentes selon des délais qui n'avaient rien d'uniforme. Un projet d'automatisation construit sur l'hypothèse « pareil pour tous » aurait fonctionné pour un seul gestionnaire et échoué silencieusement sur les autres, exactement le type de scénario que les scénarios non nominaux qui tuent un projet SI en silence décrit une fois qu'il arrive en production plutôt qu'en amont.

L'écart n'était pas anecdotique : sur un gestionnaire, la confirmation de raccordement arrivait par email sous quelques jours ; sur un autre, elle nécessitait une connexion à un portail dédié et pouvait prendre plusieurs semaines sans notification automatique. Un outil pensé pour le premier cas aurait tout simplement affiché un dossier « en attente » indéfiniment sur le second, sans qu'aucune erreur ne se déclenche pour alerter qui que ce soit. La variante n'était pas un détail de confort, elle déterminait si le suivi restait fiable ou basculait dans l'angle mort.

Cette semaine, reprenez la dernière affirmation « ça fonctionne pareil » que vous avez entendue ou prononcée sur un processus impliquant un tiers externe, et posez-lui les trois questions du mécanisme avant de la considérer comme acquise.