Une entreprise est un seul produit. Et chaque mauvais processus en est la dette technique.

La plupart des entreprises n'ont jamais été conçues. Elles ont poussé. Au départ, il y avait un fondateur et un tableur, puis un commercial avec sa propre liste de contacts, une comptable avec son propre logiciel, une production avec sa propre planification. Chaque décision était défendable sur le moment, leur somme au bout de dix ans n'a presque jamais de sens.

Un modèle plus utile existe : l'entreprise est un seul produit. Elle a des utilisateurs, des interfaces, des flux, des bases de données, du legacy, des défauts et une expérience d'usage. Et comme tout produit logiciel, elle porte une dette technique dont on paie les intérêts, même si aucun plan comptable ne les enregistre.

Ce n'est pas une métaphore destinée à faire joli, mais un modèle de travail qui déplace l'endroit où vous cherchez le problème. Si l'entreprise est un produit, une facturation lente n'est pas la défaillance d'un service, c'est un défaut dans le flux. Et un défaut ne se corrige pas par une formation, mais en redessinant le flux.

L'entreprise n'est pas née d'un coup, elle a poussé couche par couche

Les services naissent en réponse à une douleur. Une personne seule ne suit plus, alors on en recrute deux, avec leur propre outil et leur propre indicateur. À partir de là, chaque service optimise ce sur quoi il est mesuré : le commerce compte les signatures, la production son taux d'utilisation des capacités, la finance le délai d'encaissement, le support le délai de première réponse. Chacun de ces indicateurs est raisonnable pris isolément.

L'optimum local d'une couche fabrique pourtant presque toujours du travail supplémentaire dans la couche d'à côté. Exemple type : un commercial négocie un délai de paiement hors standard, parce qu'on le mesure au nombre de contrats. La finance traite ensuite une exception à la main, la production hérite d'une échéance que personne n'avait prévue, et le support explique pourquoi la facture ne correspond pas à l'offre. Personne n'a commis de faute, c'est le système qui est mal conçu.

Du point de vue du client, il n'existe qu'une seule entreprise

Le client ignore où s'arrête le commerce et où commence la facturation. Il voit une seule chaîne de points de contact et la vit comme une seule expérience. L'expérience client, c'est-à-dire le vécu du client sur toute la durée de la relation, n'est pas la moyenne de ces points de contact. Elle se rapproche plutôt du maillon le plus faible : on retient mieux un raté qu'un déroulement fluide, et c'est lui qui sert à juger toute la relation.

C'est pourquoi un processus se mesure sur toute sa longueur, et non service par service. La question n'est pas de savoir à quelle vitesse travaille l'entrepôt, mais combien d'heures s'écoulent entre la commande et la livraison, et où le colis ne fait qu'attendre.

Trois groupes d'utilisateurs pour un même produit

Chaque groupe utilise une partie différente.

• Le client utilise l'interface publique : le site, l'offre, la commande, la facture, le support.
• Le collaborateur utilise l'interface interne : les systèmes, les formulaires, les validations et les tableurs que personne n'a conçus pour lui, qui se sont simplement accumulés.
• La direction utilise la couche de données et de reporting sur laquelle elle fonde ses décisions.

Les budgets, eux, ne suivent généralement pas ce découpage. L'interface publique a un responsable et un indicateur, l'interne n'a le plus souvent ni l'un ni l'autre, si bien qu'on n'y investit pas tant que rien ne brûle. Or l'expérience collaborateur, c'est-à-dire le vécu des salariés face aux outils et aux règles de leur propre entreprise, se répercute sur la performance. Selon une étude du MIT Center for Information Systems Research de 2017, menée auprès de 281 cadres dirigeants, les entreprises du quartile supérieur en expérience collaborateur étaient deux fois plus innovantes que celles du quartile inférieur, mesurées à la part du chiffre d'affaires issue des nouveaux produits et services, et affichaient une valeur supérieure de 25 % sur un indicateur sectoriel de rentabilité. Il s'agit de corrélations issues de l'auto-évaluation de dirigeants, pas d'une causalité démontrée. Reste que le temps passé à contourner son propre système ne crée de valeur pour personne.

Un processus est un parcours utilisateur que personne n'a dessiné

En design produit, le user flow désigne la suite d'étapes que l'utilisateur traverse pour atteindre son objectif. Chaque étape superflue coûte du temps et augmente le risque d'erreur. Un processus d'entreprise, c'est exactement la même chose, sauf que personne ne l'a jamais testé.

La friction se chiffre avec une formule que nous appelons Cost of Friction : la durée d'une occurrence multipliée par la fréquence, par le nombre de personnes impliquées et par le coût horaire. Une étape qui ne dure qu'un instant, mais que tout un service répète chaque jour, revient souvent plus cher qu'un projet traité une fois par an. Sans ce calcul, les priorités se décident selon celui qui crie le plus fort. Nous avons expliqué en quoi le design est un outil d'économie de temps et d'argent dans le texte Le bon design n'est pas une décoration.

Les systèmes internes sont l'interface de l'entreprise, la marque n'en est que la page de couverture

Dans notre modèle, l'entreprise compte cinq couches : Brand, Experience, Systems, Automation, Intelligence. La marque est l'interface externe, autrement dit la promesse. Les systèmes internes sont l'interface par laquelle quelqu'un tient réellement cette promesse. Quand les deux divergent, c'est toujours la promesse qui perd : une entreprise peut soigner son identité visuelle et envoyer la confirmation de commande depuis la boîte mail personnelle du magasinier.

L'inverse vaut aussi : un système interne que personne ne veut utiliser n'est pas un problème de discipline, mais de conception. Les gens contournent les outils de leur entreprise pour la même raison que les clients abandonnent un mauvais panier : le chemin est plus long qu'il ne devrait l'être.

Les données sont une infrastructure, pas du reporting

Si le même client existe dans cinq systèmes en cinq versions différentes, l'entreprise n'a pas de client. Elle a cinq hypothèses. L'architecture de données, c'est-à-dire l'accord sur l'endroit où naît la vérité concernant le client, la commande et le prix, est une infrastructure au même titre que l'électricité. On ne la voit pas tant qu'elle ne tombe pas.

C'est pourquoi les couches Automation et Intelligence ne peuvent pas se construire avant la couche Systems. Automatiser sur des données incohérentes n'accélère pas l'entreprise, cela ne fait que multiplier l'erreur plus vite. Nous l'avons décrit dans l'article L'IA ne sauvera pas un mauvais processus.

Un processus legacy est une dette technique, et elle porte intérêt

La métaphore de la dette technique a été introduite par Ward Cunningham en 1992, et son sens d'origine est plus précis que ce qu'on en cite aujourd'hui : la dette n'est pas synonyme de travail bâclé, c'est une simplification temporaire et assumée qui accélère le travail, à condition d'être remboursée rapidement par une réécriture. Ce n'est pas l'emprunt qui est dangereux, c'est le non-remboursement. Chaque minute passée à travailler avec du code qui n'est pas tout à fait juste constitue, selon Cunningham, un intérêt.

Traduit à l'échelle de l'entreprise : un processus legacy est une procédure qui a survécu à sa propre raison d'être. Le rapport part tous les lundis parce qu'un manager l'avait demandé il y a des années, et qu'il ne travaille plus dans l'entreprise. Personne ne l'a arrêté, parce que cela ne fait mal à personne assez fort.

Les intérêts sont mesurables. Selon l'étude longitudinale de Besker, Martini et Bosch, dans laquelle 43 développeurs ont consigné leur travail pendant sept semaines, les développeurs perdent en moyenne 23 % de leur temps à cause de la dette technique. Il s'agit des estimations des participants eux-mêmes, pas d'une mesure objective. L'étude met aussi en évidence une seconde propriété de la dette : dans environ un quart des situations où ils la rencontrent, les développeurs sont contraints d'en créer une nouvelle. La dette se reproduit d'elle-même, exactement comme un processus dans lequel une exception se règle par une exception supplémentaire.

Le consortium CISQ estime la dette technique accumulée dans le logiciel aux États-Unis à environ 1 520 milliards de dollars. Le rapport reconnaît lui-même qu'il s'agit de l'ajustement pour inflation d'une estimation plus ancienne et qu'il ne dispose pas encore d'une bonne estimation des intérêts. La conséquence est plus instructive : la dette technique est devenue le principal obstacle aux changements dans le code existant. En entreprise, la même phrase se dit simplement : « chez nous, ça ne peut pas changer. »

Les silos ne sont pas un problème de culture, mais d'intégration

En 1968, Melvin Conway a formulé l'observation que nous connaissons sous le nom de loi de Conway : les organisations qui conçoivent des systèmes sont contraintes de produire des conceptions qui copient leurs propres structures de communication. Selon lui, une rupture dans l'organisation se retrouve dans la structure du système. Il ne s'agissait pas d'une étude empirique, mais d'un essai tiré de la pratique.

La confirmation est venue plus tard. Des chercheurs de Microsoft Research et de l'University of Maryland ont analysé le développement de Windows Vista, précisément 3 404 binaires et plus de 50 millions de lignes de code. Les métriques de structure organisationnelle ont prédit les parties du système sujettes aux défauts avec une précision de 86,2 % et un rappel de 84,0 %, dépassant le volume des modifications de code, la complexité et la couverture de tests. Les auteurs rappellent qu'il s'agit d'une seule entreprise et d'un seul produit, mais l'organisation des personnes a mieux prédit les défauts que les propriétés du code. L'étude de MacCormack, Rusnak et Baldwin y ajoute l'effet miroir : dans un logiciel financier, la modification d'un seul fichier pouvait toucher en moyenne 7,74 % du système dans une organisation faiblement couplée, contre 47,14 % dans une organisation fortement couplée.

Deux choses en découlent. Si deux services se transmettent leur travail par e-mail, votre intégration de données ressemblera exactement à cela. Et l'on peut retourner le raisonnement : la démarche appelée Inverse Conway Maneuver modifie délibérément la structure des équipes pour en faire émerger l'architecture souhaitée. Selon le rapport DORA de 2022, les équipes très performantes qui atteignent leurs objectifs de fiabilité avaient 40 % de probabilité en plus de s'appuyer sur une architecture faiblement couplée, c'est-à-dire une architecture où une équipe mène un changement d'ampleur sans attendre les autres équipes. Il s'agit d'une corrélation issue d'une enquête déclarative menée auprès de plus de 1 350 professionnels.

La refonte d'une entreprise se mène comme la refonte d'un produit

La séquence est la même que pour un produit, et elle ne se saute pas.

1. Recherche. Des entretiens avec les personnes qui font réellement le travail, pas avec leurs supérieurs. Ce qui nous intéresse, c'est la réalité, pas la procédure écrite.
2. Cartographie. Un processus de bout en bout, avec toutes les attentes, les ressaisies et les exceptions.
3. Priorisation. Le Cost of Friction, plus la question de savoir où un petit changement produit un grand effet. Donella Meadows appelle ces endroits des points de levier et cite l'entreprise directement comme exemple de système complexe. Elle reprend au passage Jay Forrester : en général, les gens trouvent le bon levier, ils poussent simplement dans le mauvais sens.
4. Prototype. Le nouveau mode opératoire sur une seule équipe, avec des mesures, et non un déploiement à l'échelle de l'entreprise.
5. Implémentation. C'est seulement ici qu'arrive l'outil. La technologie est la dernière décision, pas la première.
6. Mesure. Le même indicateur avant et après. Sans cela, ce n'est qu'une opinion.

Une règle d'ordonnancement stricte domine toute la séquence : supprimer, simplifier, automatiser, augmenter. Commencez par éliminer ce qui est inutile, simplifiez ensuite ce qui reste, automatisez seulement après, et augmentez enfin les capacités humaines par des outils, IA comprise. Qui démarre à la troisième étape s'achète une version plus chère de son problème initial. À quoi ressemblerait une entreprise construite depuis zéro, nous l'avons détaillé dans le texte Une entreprise sans armée administrative.

Ce qu'il ne faut jamais automatiser sans comprendre les gens

N'automatisez pas un processus que vous ne comprenez pas dans le détail, qui est truffé d'exceptions ou que vous n'avez jamais vu s'exécuter en conditions réelles. L'automatisation est du béton : elle coule exactement la forme qu'on lui donne, déformations comprises.

Les contournements non documentés sont une information, pas un sabotage. Ils signalent précisément l'endroit où le système est mauvais. W. Edwards Deming estimait qu'environ 94 % des problèmes relèvent du système et de la responsabilité du management, les 6 % restants tenant à des causes spéciales. Il l'a formulé comme une estimation personnelle tirée de son expérience, pas comme une grandeur mesurée. Cela n'en décrit pas moins exactement pourquoi remplacer les personnes n'aide que rarement. D'après les notes d'un participant à son séminaire de 1993, il l'a dit plus crûment encore : un mauvais système battra un bon collaborateur à tous les coups.

Encore une chose qu'on entend rarement dans notre métier : tout problème n'appelle pas son propre logiciel. Une partie des processus se corrige en supprimant un rapport, avec un seul formulaire partagé ou un outil sur étagère à quelques dizaines d'euros par mois. Une solution sur mesure n'a de sens que là où le processus est réellement spécifique et où sa friction dépasse le coût du développement et de la maintenance. Qui propose du développement avant d'avoir compris le processus vend un outil, pas une solution.

Une entreprise n'est pas une collection de services. C'est un système

La pensée systémique tient en une seule discipline : évaluer le comportement de l'ensemble, pas la performance des parties. Une entreprise qui a cinq excellents services et cinq mauvaises transitions entre eux est lente. Les retards et les erreurs ne naissent pas dans les services, mais dans les passages de relais, là où le processus n'a pas de propriétaire.

Si vous acceptez que l'entreprise est un seul produit, les questions changent aussi. À la place de « qui a raté ça », vient « à quel endroit du flux cela se produit », à la place de « achetons un système », vient « quelle étape n'a aucune raison d'exister ici ». Et à la place d'une grande transformation, vient une série de petites interventions aux endroits où le levier est le plus fort. Le premier pas n'est ni un achat ni une réorganisation, mais le diagnostic honnête d'un flux précis.

Ce qu'il faut retenir

• Choisissez un processus qui touche le client et cartographiez-le du premier contact jusqu'à la facture payée, temps d'attente compris.
• Calculez le Cost of Friction : la durée multipliée par la fréquence, par le nombre de personnes et par le coût horaire. Ne décidez de l'ordre des changements qu'ensuite.
• Dressez la liste de vos processus legacy avec une seule question posée à l'équipe : que faisons-nous uniquement parce qu'on a toujours fait ainsi ? Tout ce qui n'a plus de raison valable est une dette exigible.
• Tenez l'ordre supprimer, simplifier, automatiser, augmenter. Automatiser un mauvais processus n'en est qu'une version plus chère.
• Avant d'acheter un outil, répondez à la question de savoir quelle étape il supprime. Si aucune, vous n'achetez pas une solution, mais une couche de plus.