1. Introduction

Demandez à un service informatique comment il se porte et il répondra dans sa propre langue : la disponibilité à trois neuf, le centre de services dans les clous de ses objectifs, la migration conforme au plan, l’audit réussi, la feuille de route tenue. Demandez aux personnes que le service existe pour servir comment se porte l’informatique et la réponse sera dans une tout autre langue : ce dont elles avaient besoin a pris une semaine, le nouveau portail compte une étape de plus que l’ancien, le rapport dont elles dépendent est une feuille de calcul qu’elles tiennent en dehors du système, et le moyen le plus rapide d’obtenir quoi que ce soit est de connaître quelqu’un. Les deux réponses peuvent être vraies en même temps, et lorsqu’elles le sont, le service souffre d’un trouble que cet article nomme et dissèque : il s’est tourné vers l’intérieur, et a pris son propre monde pour le monde.

Nous empruntons le mot solipsisme à dessein. En philosophie, c’est la position selon laquelle seul l’esprit du sujet est certain d’exister et tout le reste est une inférence qui pourrait se tromper. Une organisation ne peut pas littéralement tenir cette croyance, mais elle peut se comporter comme si elle la tenait. Un service informatique se comporte de façon solipsiste lorsque ses propres artefacts — les systèmes qu’il exploite, les indicateurs qu’il tient, la feuille de route qu’il défend, l’architecture vers laquelle il tend — deviennent les choses qu’il traite comme réelles, et que les utilisateurs, le travail et les résultats deviennent une inférence qu’il tire de ses propres instruments, pour l’essentiel des tickets. L’inférence est lacunaire, et le service ne remarque pas la perte, parce que les instruments continuent d’afficher le vert. Ce n’est pas de la bêtise et c’est rarement de la mauvaise foi. C’est la dérive naturelle de tout groupe qui est mesuré sur sa propre activité, isolé des personnes qu’il sert par une couche de tickets et de chargés de clientèle, et récompensé par une hiérarchie qui voit les mêmes chiffres tournés vers l’intérieur que lui.

Ce schéma n’est pas propre à l’informatique. C’est une défaillance reconnue des organisations en général, parfois appelée solipsisme d’entreprise : une entreprise qui agit comme si sa marque, ses indicateurs et ses objectifs internes étaient le centre de la vie de ses clients, coupée des personnes et des réalités qui existent hors de ses murs. La campagne marketing qui enchante le conseil d’administration et meurt sur le marché, la réorganisation qui optimise l’organigramme et non le travail, l’obsession du contrôle de haut niveau sur une abstraction tandis que le travail de terrain qui fait tourner l’entreprise est ignoré, sont autant de formes du même repli sur soi. Cet article transpose ce schéma au service informatique, où il prend ses formes caractéristiques, ses propres instruments d’auto-illusion et, nous le soutiendrons, son propre remède.

La contribution est un vocabulaire et un petit modèle, non une nouvelle théorie. Le vocabulaire tient en quatre manifestations (section 3), chacune étant la forme informatique d’un original d’entreprise. Le modèle (section 4) sépare la valeur que le métier réalise du travail que le service comptabilise, et met au jour le mécanisme — la demande d’échec — par lequel les deux peuvent évoluer en sens inverse, de sorte que le service paraît le plus en forme sur les tableaux de bord précisément là où il sert le plus mal. Du modèle nous tirons un ensemble d’indicateurs d’alerte précoce et leurs substituts tournés vers l’extérieur (section 5). La question que pose donc l’article est la suivante : comment un service informatique en vient-il à confondre ses propres instruments avec le métier qu’il sert, comment peut-il s’en apercevoir, et comment retourne-t-il le regard vers l’extérieur ?

L’article est écrit pour la situation néerlandaise, qui donne au schéma une clarté inhabituelle (section 6). L’idée organisatrice de la gouvernance informatique néerlandaise de ces quinze dernières années — la regieorganisatie qui sépare une organisation de la demande d’une organisation de l’offre — institutionnalise exactement la distance entre le service et le travail qui nourrit le repli sur soi ; et une décennie de revues publiques, de l’enquête parlementaire sur les TIC à l’organe de contrôle permanent qui lui a succédé, est pour l’essentiel le récit de projets informatiques publics qui servaient leur propre logique plutôt que celle du citoyen. La section 7 retrace un cas construit. Les sections 8 à 11 exposent le remède, répondent aux objections, énoncent les limites et concluent.

2. Contexte et travaux connexes

2.1 Le solipsisme comme métaphore organisationnelle

Que les organisations perdent le contact avec leur extérieur est une observation ancienne qui court sous bien des noms. Janis (1972) a décrit le groupthink, la tendance d’un groupe soudé à converger vers une vision qui préserve sa propre harmonie aux dépens de l’épreuve de la réalité. Beer (1979) a bâti toute une cybernétique de la gestion sur le principe qu’une organisation n’est viable que si son modèle interne du monde est corrigé par des canaux qui font entrer l’extérieur, et qu’elle défaille lorsque ces canaux s’atrophient ; sa formule selon laquelle la finalité d’un système est ce qu’il fait, et non ce qu’il dit faire, est le diagnostic que cet article applique aux tableaux de bord. Weick (1995) a montré comment les organisations mettent en acte l’environnement qu’elles tiennent ensuite pour donné, de sorte qu’une unité tournée vers l’intérieur ne se contente pas de mal lire son monde mais en fabrique en partie les relevés. Aucun de ces auteurs n’a écrit sur les services informatiques, mais chacun a décrit le mécanisme par lequel un groupe en vient à vivre à l’intérieur de son propre récit des choses.

2.2 La vue de l’intérieur et la vue de l’extérieur

La description la plus exacte de l’erreur cognitive revient à Kahneman et Lovallo. La vue de l’intérieur prévoit un projet à partir des détails du projet lui-même — le plan, l’équipe, le diagramme de Gantt ; la vue de l’extérieur le prévoit à partir de l’historique de projets semblables, dont la plupart ont pris du retard (Lovallo & Kahneman, 2003). La vue de l’intérieur paraît plus rigoureuse parce qu’elle est construite à partir de ce que le planificateur peut voir, et elle se trompe de façon fiable, parce que ce que le planificateur peut voir est la machinerie propre du service et non le taux de base du monde. Un service informatique qui planifie, mesure et rend compte depuis la vue de l’intérieur est solipsiste précisément au sens technique : il raisonne à partir de ses propres contenus et traite l’extérieur comme une inférence. Le remède que proposent les auteurs — s’ancrer sur l’historique extérieur — est le remède que cet article propose pour les indicateurs.

2.3 La valeur telle que l’utilisateur en fait l’expérience

Une littérature parallèle insiste sur le fait que la valeur n’est pas créée par un fournisseur puis livrée, mais réalisée par un utilisateur dans l’usage. La logique à dominante de service (Vargo & Lusch, 2004) le pose de façon générale : le fournisseur ne peut qu’offrir une proposition de valeur, et la valeur est co-créée et déterminée par le bénéficiaire dans son propre contexte. La tradition des jobs-to-be-done le rend opérationnel : les gens ne veulent pas un produit, ils l’engagent pour progresser sur une tâche qui surgit dans leur vie, et l’unité d’analyse est la tâche, non le produit (Christensen et al., 2016 ; Ulwick, 2005). Von Hippel (1986) a montré que les utilisateurs à la pointe d’un besoin sont souvent une meilleure source de ce qu’il faut construire que la planification propre du fournisseur. La tradition de conception de Norman (2013) dit la même chose du côté de l’usage : un système devrait être façonné autour des objectifs de l’utilisateur et de la structure de sa tâche, et un système façonné autour du modèle que le fournisseur se fait de lui-même est la façon standard de produire quelque chose d’inutilisable. Lus ensemble, ces travaux disent que la production d’un service informatique n’est pas des systèmes mais le travail que ces systèmes permettent aux gens d’accomplir, et que le service ne peut pas voir cette production depuis l’intérieur.

2.4 L’écart entre le plan et le travail

Enfin, une tradition en systèmes d’information a documenté, à maintes reprises, que le système formel et le travail réel divergent, et que c’est dans la divergence que la valeur vit ou meurt. Suchman (1987) a montré que l’action humaine est située, improvisée face aux particularités du moment, et seulement vaguement régie par les plans censés la diriger, de sorte qu’un système construit à partir du plan est inadapté au travail. Ciborra (2002) a décrit comment les systèmes d’information réels dérivent des intentions de leurs concepteurs à mesure que les gens les font fonctionner par bricolage et contournement, et a soutenu que le contournement est une donnée sur l’inadéquation, non de la désobéissance. Markus (1983) et Keen (1981) ont montré que la résistance des utilisateurs à un système est généralement une réponse rationnelle à la manière dont le système redistribue l’effort et le pouvoir, et donc un signal à lire plutôt qu’un obstacle à surmonter. Orlikowski (2000) a reformulé la technologie comme quelque chose qui se constitue dans l’usage plutôt que s’incarne dans l’artefact. Le constat commun est que la vérité de terrain d’un système informatique est entre les mains des personnes qui l’utilisent, soit exactement l’endroit où un service solipsiste ne regarde pas. Les systèmes fantômes qui en résultent — les feuilles de calcul et les outils non autorisés — sont devenus un champ d’étude à part entière (Haag & Eckhardt, 2017) ; nous les lisons à la section 3 comme le message le plus clair que le métier envoie au sujet de l’inadéquation, et celui qui est le plus souvent mal entendu.

3. Quatre manifestations

Nous nommons quatre formes que prend le repli sur soi dans un service informatique. Elles se chevauchent et se renforcent mutuellement, mais chacune a un signe distinctif, et les nommer séparément permet à un service de trouver celle dont il souffre. Le tableau 1 place chacune à côté de son original d’entreprise et de son signe de terrain.

3.1 L’illusion de centralité

La première manifestation est la croyance que le métier pense à l’informatique à peu près autant que l’informatique pense à elle-même. Le service a une marque à ses propres yeux : un nom, un portail, un catalogue de services, un ensemble de valeurs affichées sur un mur, une feuille de route dont il est fier. Il imagine l’utilisateur arrivant sur le portail avec attention et intention, lisant l’annonce, appréciant la nouvelle fonctionnalité, se souciant de la version dont il s’agit. L’utilisateur ne fait rien de tout cela. L’utilisateur est au milieu d’une journée qui porte sur la conclusion d’une vente, le soin d’un patient, la réservation d’un transport ou l’animation d’un cours, et le système est une chose qu’il doit traverser pour poursuivre, idéalement sans s’en apercevoir. Son interaction avec l’informatique est brève, instrumentale et de mauvaise grâce, l’un des dizaines d’outils qui se disputent une bribe de son attention, et le sentiment qu’il y apporte est au mieux neutre et au pire l’irritation d’une interruption.

L’illusion coûte cher parce qu’elle fixe le mauvais objectif. Un service qui croit occuper de la place dans l’esprit de l’utilisateur construit pour l’engagement : des portails avec des actualités, des tableaux de bord pour tout le monde, des fonctionnalités qui invitent à l’exploration, des notifications qui s’annoncent. Un service qui comprend qu’il n’occupe qu’un instant de mauvaise grâce construit pour l’effacement : le moins d’étapes possible, les valeurs par défaut les plus solides, le système qui fait la chose évidente sans qu’on le lui demande puis s’écarte. Les deux construisent des choses opposées, et seul le second sert un utilisateur dont l’attention est ailleurs. L’illusion de centralité est la raison pour laquelle tant d’outils internes sont conçus comme des destinations alors qu’ils devraient être conçus comme des portes.

3.2 La chambre d’écho interne

La deuxième manifestation est une gouvernance qui sélectionne ce qui plaît au service plutôt que ce qui sert le travail. Une idée — une nouvelle plateforme, une norme, un portail en libre-service, une réorganisation du support — naît au sein de l’informatique et doit survivre à une série d’instances internes : un comité d’architecture, un comité consultatif sur les changements, un comité de pilotage, une réunion d’état-major du DSI. Chaque instance juge l’idée à l’aune de critères internes — élégance, standardisation, stratégie fournisseurs, répartition des coûts, contrôle — et une idée qui flatte ces critères passe, ralliant des parrains à mesure qu’elle grimpe. Au moment où elle atteint le métier, elle a été affinée pendant des mois selon les préférences de gens qui ne l’utiliseront jamais, et elle rencontre le travail pour la première fois au lancement, où elle échoue, non parce que l’ingénierie était médiocre mais parce qu’aucun canal extérieur ne s’est jamais trouvé sur son chemin. Le portail que personne n’a demandé, l’outil en libre-service qui génère plus d’appels qu’il n’en évite, la migration qui a résolu un problème informatique et en a créé un pour le métier, sont autant de produits d’un processus de revue sans fenêtre sur l’extérieur.

La chambre d’écho est la forme informatique de la campagne sourde qui enchante la salle du conseil et meurt sur le marché. Sa signature est que l’échec surprend. Un service dont les idées sont éprouvées face au travail s’attend à ce que certaines échouent et apprend à peu de frais ; un service dont les idées sont éprouvées face à lui-même est régulièrement stupéfait, parce que tous ceux qu’il a consultés étaient d’accord. Le remède n’est pas de meilleures instances mais une porte différente : une idée devrait rencontrer un utilisateur réel accomplissant un travail réel avant d’accumuler des parrains internes, et non après, afin que l’extérieur puisse la tuer tant que la tuer coûte encore peu.

3.3 Le décrochage par l’abstraction

La troisième manifestation est l’attention que la direction porte au contrôle de haut niveau et à l’abstraction au détriment du travail de terrain qui fait tourner l’entreprise. La conversation des cadres porte sur l’architecture cible, la source unique de vérité, la plateforme, la posture cloud, la stratégie de données, le panneau d’affichage unique — des abstractions attirantes précisément parce qu’elles promettent le contrôle depuis le haut sans contact avec le désordre d’en bas. Pendant ce temps, l’entreprise tourne en réalité sur un substrat que l’abstraction ne modélise pas : le traitement par lots nocturne qu’une seule personne comprend, le rapprochement que quelqu’un fait à la main chaque mois, l’intégration maintenue par un export planifié, le savoir tacite de quel système croire quand deux se contredisent. Ce travail est invisible depuis le sommet parce qu’il n’apparaît pas sur le schéma d’architecture, et un service pris dans l’abstraction prend le schéma pour le territoire.

Le décrochage est dangereux précisément aux moments où l’abstraction est censée aider. Une consolidation sur la plateforme unique, planifiée à partir du schéma, découvre trop tard que le système décommissionné était porteur d’une manière qu’aucun schéma ne montrait, parce que son rôle réel vivait dans un contournement. La carte omettait le pont que le trafic empruntait réellement. L’architecture d’entreprise en tant que discipline n’est pas le problème ; le problème est l’architecture pratiquée comme un acte tourné vers l’intérieur, dessinant le système que le service aimerait exploiter plutôt que découvrant le système qu’il exploite. Le remède est ethnographique avant d’être architectural : aller observer le travail, trouver les rapprochements faits à la main et les feuilles de calcul porteuses, et les traiter comme la spécification de ce que la plateforme ne doit pas casser.

3.4 La lentille tournée vers l’intérieur

La quatrième manifestation sous-tend les trois autres : l’habitude de tout regarder à travers des indicateurs qui décrivent le fonctionnement propre du service plutôt que le résultat pour l’utilisateur. Disponibilité, délai moyen de résolution, tickets clôturés, taux de réussite des changements, jalons de projet atteints, respect du budget, constats d’audit clos — ce sont les instruments sur le mur, et chacun d’eux mesure quelque chose qui se passe à l’intérieur de l’informatique. Aucun ne mesure si une personne a pu accomplir son travail, combien de temps sa tâche a réellement pris de bout en bout, quelle part de son effort est passée à lutter contre les outils, ni si la chose dont elle avait besoin existe seulement. La lentille pointe vers l’intérieur, et ce qu’elle ne peut pas voir, elle ne peut pas le gérer.

La lentille tournée vers l’intérieur n’est pas seulement incomplète ; elle est activement trompeuse, parce que les indicateurs internes peuvent être optimisés de manières qui nuisent au résultat externe. Un centre de services mesuré au nombre de tickets clôturés et au délai de clôture apprend à clôturer des tickets, ce qui n’est pas la même chose que résoudre des problèmes ; une clôture rapide et superficielle qui ne corrige pas la cause sous-jacente produit un second ticket, et le service qui comptabilise les deux comme du débit voit de la productivité là où l’utilisateur voit un problème qui a demandé deux appels. C’est le mécanisme que la section suivante modélise, et c’est la raison pour laquelle un service peut être au vert sur chaque tableau de bord alors que le métier qu’il sert ne l’est pas. La conception centrée sur l’utilisateur est, au fond, la consigne de retourner cette lentille : partir de l’objectif de l’utilisateur et regarder en retour vers l’informatique, plutôt que de partir du fonctionnement de l’informatique et d’en inférer l’utilisateur.

4. Un modèle minimal : l’écart de solipsisme

Les quatre manifestations partagent une conséquence mesurable : un écart entre ce que le service comptabilise et ce que le métier réalise. Cette section donne un petit modèle de cet écart, juste assez pour montrer pourquoi les deux peuvent diverger et pourquoi la divergence s’auto-entretient. Le modèle est une esquisse destinée à rendre le mécanisme explicite, non un calibrage.

4.1 Deux sortes de demande

Suivons la tradition de la gestion des services en scindant le travail qui arrive à un service informatique en deux sortes (Seddon, 2008). La demande de valeur est un travail que le métier veut véritablement voir accompli : une nouvelle capacité, un changement réel, une question qui a besoin d’une réponse. La demande d’échec est un travail créé par l’incapacité antérieure du service à faire quelque chose, ou à le faire correctement : l’utilisateur qui rappelle parce que le premier correctif n’a pas tenu, la demande d’un contournement pour un système qui n’aurait pas dû en exiger un, le ticket rouvert, la seconde visite. Soit la demande totale sur une période

et définissons le ratio de solipsisme comme la part du travail du service qui porte sur ses propres échecs antérieurs,

Le ratio est bien nommé. Un service avec un $\sigma$ élevé consacre l’essentiel de son effort à répondre aux conséquences de son propre travail — un repli littéral de l’activité sur elle-même — et pourtant chaque unité de cet effort apparaît dans les indicateurs internes comme un ticket traité et un problème clos.

4.2 Pourquoi les chiffres et la valeur divergent

Soit la production mesurée du service — la quantité que rapporte la lentille tournée vers l’intérieur — le total du travail qu’il traite, qui en première approximation est tout $D$ : chaque ticket clôturé, de valeur ou d’échec, compte. Soit la valeur réalisée — la quantité dont le métier fait l’expérience — la demande de valeur réellement satisfaite, nette de la friction qu’imposent les échecs, de sorte qu’elle décroît à mesure que $\sigma$ augmente. En notant $M$ la production mesurée et $V$ la valeur réalisée en fonction du débit du service $T$ et du ratio $\sigma$,

où $q \in (0,1]$ est la mesure dans laquelle le travail livré s’adapte à la tâche réelle de l’utilisateur, la quantité que dégradent les manifestations de la section 3. L’écart entre ce qui est comptabilisé et ce qui est réalisé,

croît avec le débit, avec le ratio d’échec et avec l’inadéquation. Le service peut augmenter $M$ en augmentant $T$ — en travaillant plus dur, en clôturant plus vite — tandis que $V$ stagne ou décline, et les tableaux de bord présenteront l’effort comme un progrès. La figure 1 trace les deux quantités à mesure que l’orientation vers l’intérieur s’accroît : la performance mesurée monte tandis que la valeur réalisée décline, une paire de lames qui se croisent au point où le service paraît le plus en forme précisément lorsqu’il commence à servir le plus mal.

4.3 Pourquoi cela se renforce soi-même

L’écart ne serait qu’un problème de mesure si $\sigma$ était fixe. Il ne l’est pas, parce qu’optimiser l’indicateur interne l’alimente. La pression pour clôturer les tickets plus vite abaisse l’adéquation $q$ de chaque clôture et accroît la probabilité que le problème sous-jacent revienne sous forme de demande d’échec, de sorte que le $\sigma$ de la période suivante est plus élevé. Soit $e$ l’effort d’optimisation interne — l’attention que le service porte à ses propres indicateurs — et soit $\ell$ l’écoute vers l’extérieur, l’attention qu’il porte au travail. Un ajustement simple capture la boucle :

avec $\alpha,\beta>0$. Lorsque la pression interne domine ($\alpha e > \beta \ell$), le ratio grimpe vers un point fixe élevé : un état stable et auto-entretenu dans lequel le service est perpétuellement occupé de lui-même, perpétuellement au vert sur ses instruments, et perpétuellement coupé du travail. Ce point fixe est le solipsisme organisationnel comme régime permanent, et le seul paramètre qui éloigne le service de ce point est $\ell$, l’attention qu’il porte à l’extérieur. Chaque manifestation de la section 3 est une manière de maintenir $\ell$ près de zéro.

5. Indicateurs d’alerte précoce

Le modèle dit qu’un service ne peut pas déceler qu’il se tourne vers l’intérieur à partir de ses indicateurs internes, par construction. Il peut le déceler à partir d’un second ensemble d’indicateurs, chacun appariant un signal interne qui paraît sain avec la réalité externe qu’il cache et la mesure externe qui la révélerait. Le tableau 2 les rassemble. Les indicateurs sont diagnostiques, et non purement rhétoriques : chacun nomme un chiffre que le service pourrait commencer à collecter dès demain, et l’acte de le collecter est lui-même le premier retournement de la lentille.

Trois d’entre eux méritent un mot. Le premier est la demande d’échec en part du volume : la plupart des services mesurent le volume de tickets et se félicitent lorsqu’ils le traitent, mais ne le scindent pas, et la scission est le chiffre le plus révélateur qu’un centre de services puisse tenir, parce qu’une part croissante signifie que le service est de plus en plus occupé de lui-même. Le deuxième est le recensement de l’informatique fantôme : un service solipsiste traite la feuille de calcul tenue hors du système sanctionné comme un problème de conformité à éradiquer, alors qu’elle est un message précis sur le point où le système sanctionné est inadapté au travail ; recenser les systèmes fantômes et les lire comme des spécifications transforme une menace en la meilleure recherche gratuite que le service obtiendra jamais. Le troisième est le délai de la tâche, et non le délai du ticket : le service mesure la vitesse à laquelle il clôture ses propres enregistrements, mais l’utilisateur mesure la durée du travail entier, y compris les parties antérieures à l’ouverture d’un ticket et postérieures à sa clôture, et seul le temps de bout en bout est la chose que l’utilisateur ressent réellement.

6. La situation néerlandaise

Le schéma est général, mais le contexte néerlandais lui donne une forme exceptionnellement claire, pour deux raisons institutionnelles et une raison de marché.

6.1 La regieorganisatie et la distance qu’elle construit

L’idée dominante de la gouvernance informatique néerlandaise de ces quinze dernières années a été la regieorganisatie : une séparation délibérée entre une organisation de la demande, qui possède la relation avec le métier et décide de ce qui est voulu, et une organisation de l’offre, souvent un prestataire externe, qui le construit et l’exploite. La séparation a de réelles vertus, et nous n’y sommes pas opposés. Mais elle institutionnalise exactement la distance qui nourrit le repli sur soi. Le côté demande en vient à se mesurer à la gestion des fournisseurs — contrats honorés, niveaux de service rapportés, réunions de gouvernance tenues — et le côté offre à la livraison des services tels que spécifiés, deux activités tournées vers l’intérieur, tandis que le travail réel de l’utilisateur se tient au-delà des deux, atteint seulement par la paperasse qui circule entre eux. Une regieorganisatie qui n’est pas délibérément reliée au travail mesure la relation entre deux organisations informatiques et l’appelle performance. Le remède de la section 8 s’applique ici avec une force particulière : le véritable rôle de l’organisation de la demande est de faire entrer l’extérieur, et si elle se mesure à la gouvernance des fournisseurs, elle est devenue en catimini la chose qu’elle était censée empêcher.

6.2 Une décennie de revues publiques

L’État néerlandais a tenu un registre exceptionnellement public de l’informatique tournée vers l’intérieur. L’enquête parlementaire sur les projets informatiques de l’État (Tweede Kamer, 2014) a constaté un schéma de grands projets portés par leur propre élan et leur logique interne, insuffisamment ancrés dans le problème qu’ils étaient censés résoudre ou dans les personnes qui en utiliseraient le résultat, et a recommandé un organe permanent pour éprouver les projets face à la réalité avant et pendant la construction. Cet organe, aujourd’hui l’Adviescollege ICT-toetsing, existe précisément parce que la vue de l’intérieur ne s’autocorrige pas : un canal externe d’experts doit être construit et financé, parce que les services laissés à leurs propres instruments n’en acquièrent pas. La leçon se généralise au-delà de l’État. La raison pour laquelle le remède de cet article est institutionnel — une porte, un recensement, une mesure — plutôt qu’une exhortation à se soucier des utilisateurs, est que le souci n’est pas l’intrant rare ; l’intrant rare est un canal qui fait entrer l’extérieur, que le service le veuille ou non.

6.3 La relation d’infogérance

Sur le marché intermédiaire néerlandais, où nous, chez Nashua, travaillons, la plupart des organisations n’exploitent pas du tout un grand service informatique interne ; elles s’appuient sur un prestataire d’infogérance. Cela change la forme du risque mais non sa nature. Un prestataire est mesuré à ses niveaux de service et à son contrat, qui sont des indicateurs internes du monde du prestataire, et un prestataire qui se gère à ces seuls indicateurs peut rapporter une relation saine tandis que le personnel de son client contourne les systèmes. La discipline tournée vers l’extérieur qu’un bon prestataire doit à son client est la même qu’un service interne doit à son métier : mesurer l’achèvement des tâches du client et non seulement la disponibilité du prestataire, lire les contournements du client comme des spécifications, et comptabiliser la part de son propre travail qui est de la demande d’échec. Un prestataire qui fait cela transforme la distance de la relation d’un handicap en un avantage, parce qu’il voit le travail de nombreux clients et peut porter la vue de l’extérieur de l’un à l’autre. Un prestataire qui ne le fait pas devient un service informatique solipsiste à un cran de distance, avec un contrat en guise de conscience.

7. Un cas construit

Le cas qui suit est construit, non observé. Il existe pour montrer les manifestations et le modèle dans un seul cadre ; ses chiffres sont illustratifs. Il décrit une organisation néerlandaise de taille moyenne dotée d’un service informatique interne d’une quarantaine de personnes au service d’environ un millier de collaborateurs répartis entre les opérations, les ventes et la finance.

Sur ses propres instruments, le service connaît sa meilleure année. La disponibilité des systèmes centraux est de 99.9 pour cent. Le centre de services clôture quatre-vingt-cinq pour cent des tickets dans les objectifs, et le volume total est en hausse de douze pour cent, ce que le rapport trimestriel présente comme une productivité en hausse. La consolidation pluriannuelle de la plateforme est conforme au plan : trois systèmes hérités retirés, tout migrant vers la suite unique. L’enquête annuelle de satisfaction informatique renvoie un score respectable. Chaque diapositive est au vert, et la direction du service, lisant fidèlement ses instruments, croit bien faire.

Sous chaque chiffre au vert se cache une réalité non verte que les instruments ne portent pas. La hausse de douze pour cent du volume de tickets est pour l’essentiel de la demande d’échec : la nouvelle version de la suite a modifié un écran que l’équipe des ventes utilisait cinquante fois par jour, et la confusion qui s’ensuit engendre un flux régulier de tickets, chacun clôturé rapidement et proprement selon les critères du centre de services, aucun ne touchant à la cause. La disponibilité est mesurée par système, mais la tâche de la commande à l’encaissement traverse désormais trois systèmes et deux transferts, et le temps écoulé pour la tâche est passé de quelques heures à deux jours, un chiffre qu’aucun tableau de bord ne montre parce qu’aucun tableau de bord ne mesure la tâche. La consolidation a retiré un ancien outil de reporting dont le rôle réel, non documenté, était un export nocturne dont dépendait le rapprochement de fin de mois de l’équipe financière ; la finance l’a reconstruit sous forme de feuille de calcul tenue par un seul analyste, que le service, lorsqu’il le remarque, consigne comme de l’informatique fantôme à éliminer. L’enquête de satisfaction a obtenu un bon score parce qu’elle demandait si le centre de services était courtois et si les systèmes étaient disponibles, et non si quiconque pouvait accomplir son travail.

Le service est, selon la définition de cet article, solipsiste, et le plus frappant est que personne en son sein ne fait mal son travail. Le centre de services est véritablement rapide et courtois. Les ingénieurs ont véritablement livré la consolidation. L’architecture est véritablement plus propre. Chaque personne optimise l’indicateur qu’elle a devant elle, et chaque indicateur pointe vers l’intérieur, de sorte que la somme d’un travail compétent et bien intentionné est un service qui a tourné le dos au métier tout en croyant lui faire face. Le modèle de la section 4 nomme l’état avec précision : le débit $T$ est en hausse, le ratio $\sigma$ croît, la production mesurée $M$ monte avec le débit tandis que la valeur réalisée $V$ décline avec $\sigma$, et les deux instruments qui manquent au service — la demande d’échec en part du volume et le délai de la tâche — sont exactement les deux qui le lui auraient montré.

8. Retourner le regard vers l’extérieur

Le remède n’est pas de se soucier davantage. Les personnes du cas construit se soucient déjà, et un souci acheminé par des instruments internes produit un travail interne. Le remède est de construire des canaux qui font entrer l’extérieur, que quiconque pense ou non à regarder, et de changer ce qui est mesuré afin que l’optimisation propre du service l’attire vers le travail plutôt que de l’en éloigner. Cinq gestes découlent du modèle et des manifestations.

Mesurer la tâche, non le ticket. Ajouter au moins une mesure de résultat à chaque mesure interne : le délai de la tâche à côté du délai de résolution, l’achèvement de la tâche à côté de la disponibilité, l’adoption à côté des fonctionnalités livrées. Le but n’est pas d’écarter les indicateurs internes, qui sont utiles pour faire tourner l’exploitation, mais de leur refuser le monopole de l’attention qui laisse s’ouvrir sans témoin l’écart de la section 4.

Scinder et surveiller la demande d’échec. Classer le travail entrant en demande de valeur ou demande d’échec et suivre le ratio $\sigma$ dans le temps. C’est le diagnostic le moins coûteux de cet article et la lecture la plus directe du repli sur soi, parce qu’il mesure quelle part de l’effort du service est une réaction à lui-même.

Lire l’informatique fantôme comme une spécification. Tenir un recensement des feuilles de calcul et des outils non autorisés, et traiter chacun comme un énoncé précis du point où les systèmes sanctionnés sont inadaptés au travail. Le contournement, c’est le métier qui rédige des exigences dans la seule langue qu’il lui reste ; un service qui l’éradique détruit sa propre meilleure recherche.

Mettre un utilisateur sur le chemin avant les parrains. Changer la porte de gouvernance pour qu’une idée rencontre tôt un utilisateur réel accomplissant un travail réel, tant que la tuer coûte peu, plutôt qu’après qu’elle a gravi la hiérarchie interne et accumulé des parrains. C’est le correctif structurel de la chambre d’écho : il insère un canal extérieur en amont des canaux internes.

Aller observer le travail. Avant toute consolidation ou tout décommissionnement, envoyer quelqu’un observer le travail de terrain que l’abstraction ne modélise pas, et trouver les rapprochements faits à la main et les feuilles de calcul porteuses. Traiter ce qu’il trouve comme la spécification de ce que la nouvelle plateforme ne doit pas casser. C’est le correctif structurel du décrochage par l’abstraction, et il est ethnographique avant d’être architectural.

Aucun de ces gestes n’est coûteux, et c’est tout l’enjeu. Le solipsisme organisationnel ne se guérit pas par un budget ou une réorganisation ; il se guérit par une poignée de canaux extérieurs délibérément construits et maintenus ouverts, parce que la tendance naturelle d’un groupe isolé et mesuré vers l’intérieur est de les fermer.

9. Objections et réponses

Les indicateurs internes comptent ; on ne peut pas faire tourner une exploitation sans eux. D’accord, et l’article ne dit pas le contraire. La disponibilité et le délai de résolution sont nécessaires pour faire tourner le service. L’affirmation est plus étroite et plus tranchée : ils ne sont pas suffisants, ils décrivent le monde du service et non celui de l’utilisateur, et lorsqu’ils sont les seuls instruments sur le mur ils laissent l’écart s’ouvrir sans témoin. Le remède est l’ajout, non le remplacement.

Les utilisateurs ne savent pas ce qu’ils veulent, donc la centration sur l’utilisateur est un chemin vers le chaos. La tradition des jobs-to-be-done y répond précisément : les utilisateurs sont mauvais pour spécifier des solutions et excellents pour exhiber leurs tâches. La consigne n’est pas de demander aux utilisateurs de concevoir le système mais d’observer le travail, de lire les contournements et de mesurer le résultat, rien de quoi n’exige que l’utilisateur connaisse la réponse, seulement qu’il soit observé pendant qu’il accomplit la tâche.

Ce n’est que de la conception centrée sur l’utilisateur sous une nouvelle étiquette. En partie, délibérément. La contribution n’est pas une nouvelle méthode mais un diagnostic de la raison pour laquelle un service équipé des méthodes se tourne quand même vers l’intérieur — à savoir que sa mesure et sa gouvernance pointent toutes deux vers l’intérieur et se renforcent mutuellement — et un petit modèle de la manière dont cela produit un écart invisible depuis l’intérieur. L’étiquette nomme le mode de défaillance afin qu’un service puisse le reconnaître en lui-même.

Un prestataire d’infogérance est structurellement extérieur au métier ; ceci ne s’applique pas. Cela s’applique avec plus de force, non moins. La distance est la condition qui nourrit le repli sur soi, et un prestataire mesuré à son contrat est aussi capable de solipsisme que n’importe quel service interne, comme le soutient la section 6. L’avantage du prestataire est qu’il voit de nombreux clients et peut porter la vue de l’extérieur de l’un à l’autre, mais seulement s’il choisit de mesurer le travail du client plutôt que ses propres niveaux de service.

10. Limites et programme de recherche

Il s’agit d’une analyse destinée aux praticiens, et ses limites doivent être énoncées. Le modèle de la section 4 est une esquisse : ses quantités sont définies assez clairement pour être mesurées mais ses formes fonctionnelles sont illustratives, choisies pour rendre le mécanisme visible plutôt qu’estimées à partir de données. Les quatre manifestations sont une typologie, utile si elle aide un service à trouver son mode de défaillance, mais non une partition dont l’exhaustivité serait prouvée. La lecture néerlandaise est interprétative. Le cas construit est construit.

Les affirmations sont néanmoins testables, et les indicateurs tournés vers l’extérieur sont les instruments pour les tester. Quatre études y suffiraient. Premièrement, mesurer le ratio de solipsisme $\sigma$ sur un ensemble de services et le corréler à une mesure indépendante de la valeur réalisée par le métier ; le modèle prédit une relation négative que les indicateurs internes ne montrent pas. Deuxièmement, suivre $\sigma$ et les indicateurs internes au cours d’une période de pression sur les indicateurs internes ; le modèle prédit que $\sigma$ monte à mesure que les chiffres internes s’améliorent. Troisièmement, instrumenter le délai de la tâche à côté du délai de résolution sur un service réel et mesurer l’écart entre eux. Quatrièmement, mener le changement de gouvernance — un utilisateur sur le chemin avant les parrains — comme une intervention contrôlée et mesurer le taux d’échec au lancement face à la porte actuelle. Chaque étude n’a besoin que de mesures que l’article nomme déjà, et chacune ferait passer l’argument de l’analyse à la preuve.

11. Conclusion

Un service informatique se tourne vers l’intérieur non par incompétence ou indifférence mais par le fonctionnement ordinaire qui consiste à être mesuré sur sa propre activité, isolé du travail par une couche de tickets et de contrats, et récompensé par une hiérarchie qui lit les mêmes instruments internes que lui. Le résultat est un service qui prend ses propres systèmes, indicateurs, feuille de route et architecture pour le centre de l’entreprise et les utilisateurs pour une inférence qu’il tire des tickets — une version organisationnelle de la croyance que seul l’esprit du sujet est assuré d’exister. Nous avons nommé quatre manifestations — l’illusion de centralité, la chambre d’écho interne, le décrochage par l’abstraction et la lentille tournée vers l’intérieur — et montré, à l’aide d’un petit modèle, comment la demande d’échec permet à la production mesurée du service de monter tandis que la valeur que le métier réalise décline, de sorte que les tableaux de bord paraissent le plus en forme précisément là où le service est le plus mauvais.

Le remède n’est pas l’exhortation mais la plomberie : une poignée de canaux extérieurs délibérément construits et maintenus ouverts, parce que la tendance naturelle d’un groupe isolé et mesuré vers l’intérieur est de les laisser se fermer. Mesurer la tâche et non seulement le ticket. Scinder et surveiller la demande d’échec. Lire l’informatique fantôme comme une spécification. Mettre un utilisateur sur le chemin avant les parrains. Aller observer le travail. Chacun est peu coûteux, chacun fait entrer un morceau de l’extérieur, et ensemble ils retournent la lentille, de sorte qu’un service se mesure à la capacité du métier qu’il sert à accomplir son travail, qui est la seule mesure qui ait jamais été réelle.

Annexe A. Mesurer l’écart de solipsisme

L’écart de la section 4 peut être approché à partir de données que la plupart des exploitations de service détiennent déjà, plus deux mesures qu’elles ne détiennent généralement pas. Toutes peuvent être collectées chaque trimestre sans enquête.

Part de demande d’échec $\sigma$. Pour un échantillon représentatif d’éléments clôturés, classer chacun comme demande de valeur (un véritable besoin nouveau) ou demande d’échec (un travail causé par une incapacité antérieure à faire ou à bien faire), selon une courte règle de codage appliquée à la clôture ou sur un échantillon rétrospectif. La part de demande d’échec est $\sigma$. Écueil : coder à la clôture par le même agent qui a clôturé l’élément la sous-estime ; utiliser un échantillon indépendant.

Adéquation $q$. Approcher l’adéquation par le complément du taux de réouverture et de reprise : la fraction des éléments de demande de valeur qui sont achevés sans élément connexe ultérieur dans une fenêtre définie. Écueil : une fenêtre courte flatte $q$ ; la caler sur le cycle propre de l’utilisateur, non sur celui du centre de services.

Délai de la tâche. Pour un petit ensemble de parcours utilisateurs représentatifs, mesurer le temps écoulé pour le parcours entier, du moment où l’utilisateur a besoin du résultat au moment où il l’obtient, à travers chaque système et chaque transfert, indépendamment des frontières des tickets. Écueil : mesurer du premier ticket à la dernière clôture manque les parties de la tâche qui ne sont jamais devenues un ticket, qui sont souvent les plus longues.

L’écart. Avec $M$ le total des éléments traités et $V = M(1-\sigma)q$, l’écart de solipsisme est $G = M - V$. Rapporté en ratio $G/M = 1-(1-\sigma)q$, il est comparable d’un service à l’autre et dans le temps, et il monte lorsque la demande d’échec ou l’inadéquation monte, qui sont les deux choses que les indicateurs internes cachent.

Annexe B. Une liste de contrôle diagnostique

Les questions ci-dessous sont regroupées par manifestation. Un oui est un symptôme, non un verdict ; plusieurs réponses oui dans un même groupe localisent le mode de défaillance, et le test externe de la dernière colonne est la mesure qui le confirmerait ou l’écarterait. La liste de contrôle est délibérément conçue pour pouvoir être remplie en un après-midi, parce qu’un diagnostic qui exige un projet ne sera pas mené.

Références

Beer, S. (1979). The heart of enterprise. John Wiley & Sons. ISBN 978-0-471-27599-1.

Brynjolfsson, E. (1993). The productivity paradox of information technology. Communications of the ACM, 36(12), 66–77. https://doi.org/10.1145/163298.163309

Christensen, C. M., Hall, T., Dillon, K., & Duncan, D. S. (2016). Know your customers’ “jobs to be done.” Harvard Business Review, 94(9), 54–62. https://hbr.org/2016/09/know-your-customers-jobs-to-be-done

Ciborra, C. (2002). The labyrinths of information: Challenging the wisdom of systems. Oxford University Press. ISBN 978-0-19-924152-7.

Davis, F. D. (1989). Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly, 13(3), 319–340. https://doi.org/10.2307/249008

DeLone, W. H., & McLean, E. R. (2003). The DeLone and McLean model of information systems success: A ten-year update. Journal of Management Information Systems, 19(4), 9–30. https://doi.org/10.1080/07421222.2003.11045748

Haag, S., & Eckhardt, A. (2017). Shadow IT. Business & Information Systems Engineering, 59(6), 469–473. https://doi.org/10.1007/s12599-017-0497-x

Henderson, J. C., & Venkatraman, N. (1999). Strategic alignment: Leveraging information technology for transforming organizations. IBM Systems Journal, 38(2&3), 472–484. https://doi.org/10.1147/sj.382.0472

Janis, I. L. (1972). Victims of groupthink: A psychological study of foreign-policy decisions and fiascoes. Houghton Mifflin.

Keen, P. G. W. (1981). Information systems and organizational change. Communications of the ACM, 24(1), 24–33. https://doi.org/10.1145/358527.358543

Lovallo, D., & Kahneman, D. (2003). Delusions of success: How optimism undermines executives’ decisions. Harvard Business Review, 81(7), 56–63. https://hbr.org/2003/07/delusions-of-success-how-optimism-undermines-executives-decisions

Markus, M. L. (1983). Power, politics, and MIS implementation. Communications of the ACM, 26(6), 430–444. https://doi.org/10.1145/358141.358148

Norman, D. A. (2013). The design of everyday things (Revised and expanded ed.). Basic Books. ISBN 978-0-465-05065-9.

Orlikowski, W. J. (2000). Using technology and constituting structures: A practice lens for studying technology in organizations. Organization Science, 11(4), 404–428. https://doi.org/10.1287/orsc.11.4.404.14600

Seddon, J. (2008). Systems thinking in the public sector: The failure of the reform regime and a manifesto for a better way. Triarchy Press.

Suchman, L. A. (1987). Plans and situated actions: The problem of human–machine communication. Cambridge University Press. ISBN 978-0-521-33739-7.

Tweede Kamer der Staten-Generaal (2014). Naar grip op ICT: Parlementair onderzoek naar ICT-projecten bij de overheid. Eindrapport van de Tijdelijke commissie ICT-projecten bij de overheid (Commissie Elias). Kamerstukken II 2014/15, 33 326, nr. 5. https://zoek.officielebekendmakingen.nl/kst-33326-5.html

Ulwick, A. W. (2005). What customers want: Using outcome-driven innovation to create breakthrough products and services. McGraw-Hill. ISBN 978-0-07-140867-7.

Vargo, S. L., & Lusch, R. F. (2004). Evolving to a new dominant logic for marketing. Journal of Marketing, 68(1), 1–17. https://doi.org/10.1509/jmkg.68.1.1.24036

von Hippel, E. (1986). Lead users: A source of novel product concepts. Management Science, 32(7), 791–805. https://doi.org/10.1287/mnsc.32.7.791

Weick, K. E. (1995). Sensemaking in organizations. Sage Publications. ISBN 978-0-8039-7177-6.