Entre un objectif d’entreprise et son exécution, il y a des mots, des choix et des traductions. Un seul mot mal compris peut transformer une exigence ferme en simple option, alors que tout le monde travaille correctement sur le plan technique.

Imaginons qu’un maçon livre un mur parfait. D’aplomb, joints soignés, matériaux solides. Seulement, il se trouve trois mètres plus loin que sur le plan.

Personne ne conclura que le projet est réussi parce que le mur est au moins droit. Bien exécuté techniquement, mais au mauvais endroit, cela reste simplement faux. Remarquablement solide, même.

Dans les produits, processus et communications numériques, ces écarts se voient moins vite. Il n’y a pas de mur sur le chemin. Le code fonctionne, le brief est coché et tout a l’air soigné. Pourtant, le résultat a pu changer de sens en cours de route par rapport à ce qui était nécessaire au départ.

Parfois, un seul mot suffit.

Obligatoirement disponible n’est pas la même chose qu’optionnel

Lors d’une discussion sur la construction d’outils, j’ai formulé une exigence simple : l’approfondissement doit être disponible dans chaque outil, en interne comme pour les clients, mais il n’a pas besoin de figurer au premier niveau de l’écran.

Cette distinction compte. Au premier niveau, on veut voir rapidement ce qui se passe, ce qui demande de l’attention et quelle est l’étape suivante. Qui a besoin de plus de contexte clique pour aller plus loin. L’approfondissement est donc obligatoirement disponible. Son utilisation, elle, ne l’est pas.

En cours de route, cela a été résumé ainsi : l’approfondissement est optionnel.

Cela sonne presque pareil. Ce n’est pas le cas. Dans ma formulation, l’utilisateur choisit quand il ouvre l’approfondissement. Dans le résumé, un exécutant peut comprendre qu’il n’est peut-être pas nécessaire de le prévoir. Un mot a fait d’une exigence produit ferme une possibilité sans engagement.

Pendant la discussion, l’écart entre mon exigence et le résumé est apparu. Cette formulation laissait la possibilité d’une mise en œuvre différente de celle que j’avais en tête. Le sens peut déjà changer dans un résumé qui paraît raisonnable.

Chaque transmission est aussi une traduction

Un objectif d’entreprise va rarement directement à l’exécution. Il est discuté, résumé, mis dans un brief, transformé en écrans ou en étapes de processus, traduit en code, puis finalement testé.

Chaque étape peut être réalisée avec soin et pourtant glisser un peu. Une condition devient une préférence. Une préférence devient un exemple. Un exemple devient la norme. À la fin, le résultat correspond parfaitement à la dernière instruction, mais plus à la question d’origine.

C’est comme un plan de construction recopié avec un demi-mètre d’erreur. L’équipe suivante continue avec une grande précision sur cette nouvelle ligne. Mieux chacun exécute sa part, plus l’écart se solidifie.

Les nouvelles technologies n’aggravent pas forcément le problème, mais elles l’accélèrent et le rendent parfois plus convaincant. Un modèle rédige un brief fluide. Un développeur en tire un code correct. Un test confirme que le code fait ce que dit le brief. Aucun de ces contrôles ne prouve que l’utilisateur reçoit encore ce qui était voulu au départ.

Ce n’est pas non plus propre à l’IA. Les humains résument, comblent les silences et choisissent des mots logiques pour eux depuis bien plus longtemps. Une formulation soignée se lit simplement aussi facilement qu’une formulation juste. Fluide et juste ne sont pas synonymes.

Déléguer demande plus qu’un bon brief

Qui confie du travail, à un collègue, à un prestataire ou à un modèle, fait bien de transmettre trois choses. Un contexte auquel l’exécutant a réellement accès. Une description claire de ce qui doit en sortir. Et, après coup, un contrôle du résultat par rapport à l’intention d’origine.

Un dossier de documentation ne remplace pas cela. La documentation prouve que quelque chose a été écrit, pas que le résultat est correct.

Le fait de ne pas tout confier d’office à un modèle a déjà été abordé dans « Le modèle peut le faire. Mais qui en a donné l’autorisation ? » Cet article traite de l’autorité. Celui-ci traite du sens. Les deux relèvent de la même transmission.

L’intention doit suivre, pas seulement la phrase

On ne prévient pas cela en rendant chaque brief interminable. Plus de mots, c’est aussi plus d’occasions de confusion. Ce qui aide, c’est de dire ce qui est fixé, où l’exécution a de la marge et pourquoi une exigence existe.

Dans l’exemple, il était fixé que chaque outil devait proposer l’approfondissement. La liberté portait sur la présentation : pas tout sur le premier écran, mais un accès logique dès que quelqu’un a besoin de plus de contexte. L’objectif était un démarrage simple sans cacher d’information.

Si seuls les mots isolés suivent, « pas au premier niveau » peut se transformer en « pas nécessaire » en cours de route. Si l’objectif suit aussi, ce saut devient beaucoup plus difficile. Un concepteur, un développeur ou un relecteur peut alors vérifier si la solution retenue répond toujours au même besoin.

Hors logiciel, c’est pareil. Une promesse commerciale doit signifier la même chose dans l’exécution. Un accord juridique doit être solide et applicable pour ceux qui l’appliquent. Et quand une commande passe par plusieurs systèmes et plusieurs mains, « sans sauce » reste de préférence une instruction plutôt qu’une suggestion.

Contrôler le résultat par rapport à la vraie question

Beaucoup de contrôles qualité portent à juste titre sur l’exécution : cela fonctionne, c’est sûr, la forme est correcte et les éléments convenus sont présents.

Il faut y ajouter un contrôle. Quelqu’un explique en langage courant ce que l’utilisateur peut faire à présent, ce qui est obligatoirement présent et quel objectif d’entreprise cela sert.

Ce n’est pas une couche de cérémonie en plus. C’est la façon la plus simple de constater que chacun a entre-temps un autre mur en tête. De préférence avant que la maçonnerie soit terminée.

Pour un outil, cette relecture sonne ainsi : sur le premier écran, l’utilisateur voit ce qui se passe et quelle est l’étape suivante, et dans chaque outil, l’approfondissement nécessaire est accessible de façon logique. On ne teste pas seulement un écran ou une spécification. On teste le lien entre le choix d’origine et ce que quelqu’un vivra réellement.

Parfois, le brief était bon et l’exécution doit être corrigée. Parfois, le problème est déjà dans la formulation. Et parfois, on découvre que la question d’origine n’était pas encore assez nette. Ce n’est pas un échec. Un contrôle sert justement à cela, avant qu’un écart devienne coûteux et visible.

Droit ne suffit pas

Une bonne exécution reste essentielle. Personne n’a besoin d’un mur bien placé qui s’effondre au premier coup de vent. Seulement, la qualité technique ne remplace pas la bonne direction.

Dans mon travail, beaucoup de choses tournent autour de ce maillon intermédiaire : préserver le sens pendant qu’une question traverse différents métiers, personnes et outils. Ne pas tout exécuter moi-même, mais veiller à ce que le choix commercial, l’accord, la communication et l’exécution parlent encore de la même chose.

De la décision d’entreprise à sa mise en œuvre, sans perdre le fil : cela paraît peut-être abstrait. Jusqu’à ce qu’un mur parfaitement droit se dresse au mauvais endroit. Alors ce fil devient soudain très concret.

Sur LinkedIn, je détaille ce que je transmets lorsque je délègue du travail : lire l’article complémentaire (en néerlandais).

Wat ik meegeef als ik werk uit handen geef

Article complémentaire sur LinkedIn (en néerlandais)