Accompagnement au changement numérique
En résumé : Un changement numérique porte sur la façon dont le travail est organisé, pas sur les logiciels qu'on installe. La valeur vient de la compréhension des processus réels, de l'ordre dans lequel on s'y prend et de l'attention portée aux personnes qui devront travailler autrement — tout cela se décide avant le choix d'un outil, et souvent en réduit le besoin.
« On va se numériser » désigne rarement la même chose d'une entreprise à l'autre. Pour l'une, il s'agit d'arrêter de ressaisir les mêmes informations dans quatre endroits ; pour une autre, de savoir enfin où en sont les dossiers en cours ; pour une troisième, de remplacer un logiciel devenu impraticable sans reproduire ses défauts. Le point commun de ces situations n'est pas technique : il tient à des processus qui se sont empilés au fil du temps, que personne n'a écrits, et que chacun contourne à sa manière. Cette page décrit ce qu'un changement numérique recouvre réellement, comment on regarde une organisation avant de la modifier, comment un accompagnement se déroule, les erreurs qui reviennent le plus souvent, et les situations où la réponse honnête consiste à ne rien lancer maintenant.
Ce qu'est un changement numérique, et pourquoi ce n'est pas un achat de logiciel
En résumé : Le mot recouvre trois chantiers d'ampleur très différente : remplacer un support par un fichier, réorganiser l'enchaînement des étapes, ou rendre lisible une information qui ne l'était pas. Aucun des trois ne s'obtient en installant un produit.
Quand une entreprise annonce qu'elle va se numériser, la phrase désigne le plus souvent une intention d'achat : un logiciel de gestion, un outil de suivi, un espace partagé. L'achat est pourtant la partie la plus simple et la moins déterminante. Un outil ne fait rien de lui-même ; il rend possible une manière de travailler qu'il faut encore décider, écrire et faire adopter. C'est cette décision, et non la licence, qui produit le résultat. Cela explique une observation banale et pourtant instructive : deux entreprises équipées du même produit en tirent des bénéfices sans rapport, parce que l'une a modifié sa façon de faire et que l'autre a simplement transposé l'ancienne dans une interface neuve.
Derrière le même mot se cachent trois chantiers d'ampleur croissante. Le premier est la dématérialisation : le processus reste identique, seul le support change. Un document circule sous forme de fichier plutôt que de feuille, il devient consultable à distance et cesse de se perdre. C'est utile, c'est rapide à obtenir, et cela ne corrige rien de ce qui était déjà bancal — un enchaînement d'étapes incohérent le reste, simplement il circule plus vite. Le deuxième chantier est la réorganisation du processus lui-même : une validation disparaît parce qu'elle ne protégeait plus rien, deux étapes fusionnent, une information est saisie une seule fois à sa source au lieu d'être recopiée partout ensuite. On touche là aux rôles et aux habitudes, ce qui explique que ce chantier soit à la fois le plus rentable et le plus difficile.
Le troisième chantier porte sur ce que l'organisation sait d'elle-même : lorsque les informations cessent d'être éparpillées, des questions restées sans réponse deviennent traitables — combien de dossiers attendent, à quelle étape ils s'arrêtent, lesquels reviennent toujours en retouche. Ce n'est plus l'exécution qui change, ce sont les décisions.
Ce que l'on appelle conduite du changement désigne la matière réelle de ce travail : des habitudes prises par des personnes qui ont eu de bonnes raisons de les prendre, des rôles qui définissent la place de chacun, une responsabilité implicite sur la qualité des données que personne n'a jamais formulée, et des arbitrages laissés en suspens depuis si longtemps que l'organisation s'est construite autour. Le logiciel est la partie visible et la plus facile à commander. Ce qui décide de la réussite se joue dans des conversations sans écran : qui valide quoi désormais, qui répond quand une exception se présente, ce qu'on accepte de ne plus faire.
Reste à dire ce que le terme ne recouvre pas. Ce n'est pas un chantier informatique confié à un prestataire pendant que l'entreprise continue comme avant : la connaissance des processus appartient à ceux qui les exécutent, et aucun regard extérieur ne la remplace, il ne fait que la rendre visible. Ce n'est pas non plus un état permanent qu'on atteindrait une fois pour toutes ; ce sont des chantiers successifs, chacun avec un début et une fin identifiables. Ce n'est enfin pas nécessairement une affaire d'outils nouveaux : il est fréquent qu'une organisation dispose déjà de fonctions payées et jamais activées, et qu'un travail de mise à plat suffise à les rendre utiles.
Comment on regarde une organisation avant de la modifier
En résumé : Cartographier un processus, c'est écrire ce qui se passe réellement et non ce que dit la procédure. Les frictions se reconnaissent ensuite à des signes constants : information ressaisie, dossier en attente d'une personne, exception traitée de mémoire, contrôle refait par méfiance.
Un processus est une suite d'étapes qui va d'un événement déclencheur à un résultat : une demande arrive, quelque chose se passe, un client reçoit une réponse ou une facture part. Le cartographier consiste à écrire cette suite telle qu'elle se déroule, avec les personnes qui interviennent, les supports qu'elles utilisent réellement — un tableur, une boîte de courriel qui sert de file d'attente, un carnet — les moments de décision et les moments d'attente. La difficulté tient à l'écart entre le travail prescrit et le travail réel : la procédure écrite, quand elle existe, décrit le cas nominal, alors que le temps se consomme dans les exceptions. C'est pourquoi suivre un dossier réel de bout en bout apprend davantage qu'un entretien sur le fonctionnement général, où chacun décrit de bonne foi ce que le processus devrait être.
Les points de friction se rangent dans un petit nombre de familles, et les nommer sert à choisir le bon remède. La ressaisie apparaît quand la même information est écrite dans plusieurs endroits par des personnes différentes : elle coûte du temps, mais surtout elle fabrique des divergences. L'attente désigne un dossier qui ne progresse pas faute d'une personne disponible, pas faute de travail à faire. La recherche recouvre le temps passé à retrouver une information plutôt qu'à l'utiliser. La reprise, c'est corriger en aval une erreur introduite en amont. Le contrôle redondant, enfin, est une vérification qui existe parce qu'on ne fait pas confiance à la précédente. Chacune appelle une réponse distincte : la ressaisie demande un point d'entrée unique ou une liaison entre outils, l'attente une règle de délégation, la recherche une convention de classement et de nommage. Aucune de ces trois réponses n'est nécessairement un achat.
Vient ensuite la question des données partagées. Une organisation a besoin, pour chaque type d'information, d'un endroit qui fasse autorité : la liste des clients, celle des tarifs en vigueur, l'état d'avancement d'un dossier. Lorsque deux outils détiennent chacun leur version de la même liste, l'une des deux est fausse et personne ne sait laquelle ; les équipes finissent par se fier à celle qu'elles préfèrent, ce qui rend les écarts invisibles. Se poser la question de l'endroit qui fait foi, du format des informations et de la personne responsable de leur mise à jour est un travail préalable, sans lequel n'importe quelle liaison technique propagera simplement les erreurs plus vite. C'est aussi à ce moment qu'on examine l'interopérabilité : un outil laisse-t-il sortir ses données dans un format exploitable, sait-il se connecter à ceux déjà en place, ou impose-t-il un export manuel que quelqu'un devra refaire indéfiniment.
La dimension humaine se traite avec le même sérieux que la dimension technique, et elle se traite mal par la communication seule. Les réticences sont rarement irrationnelles : une personne qui a construit des arrangements efficaces autour d'un outil médiocre défend un système qui marche, et on lui demande de redevenir débutante dans une tâche qu'elle maîtrisait. Trois choses font davantage que n'importe quelle annonce. Faire participer les intéressés à la description du processus, parce que la corriger les rend auteurs de ce qui suit. Dire explicitement ce qui ne change pas, faute de quoi chacun imagine le pire. Et répondre clairement à la question du temps libéré, qui est posée en silence dès la première réunion et qui empoisonne le projet tant qu'elle reste sans réponse.
Reste un critère que l'on regrette toujours de ne pas avoir examiné plus tôt : la réversibilité. Chaque décision a un coût de sortie, et il vaut mieux le connaître avant de s'engager qu'après. La dépendance se crée par trois voies principales : des données enfermées dans un format que seul l'éditeur sait lire, une configuration qui n'existe que dans la tête d'une personne, et un processus reconstruit autour des particularités d'un produit au point de ne plus pouvoir s'en détacher. Les questions à poser avant de signer sont donc prosaïques et se posent bien avant les démonstrations : comment récupère-t-on ses données et sous quelle forme, qui administre l'outil au quotidien, que devient le processus si l'entreprise décide d'en changer.
Comment se déroule un accompagnement
En résumé : Observer avant de proposer, hiérarchiser plutôt que tout traiter, simplifier avant d'outiller, déployer sur un périmètre restreint, puis accompagner les équipes jusqu'à ce que l'ancienne façon de faire soit réellement arrêtée.
La première phase est une observation, pas une proposition. On s'entretient avec les personnes qui exécutent le travail plutôt qu'avec celles qui le décrivent, on suit des dossiers réels, on recueille les supports effectivement utilisés — y compris le tableur officieux qui tient tout l'édifice et dont personne ne parle en réunion. On inventorie aussi ce qui est déjà en place et déjà payé, car les fonctions dormantes sont fréquentes. Cette phase produit un document : la description écrite des processus concernés, rendue aux équipes pour correction. Cette relecture n'est pas une formalité, c'est là que remontent les exceptions oubliées, et c'est aussi le premier moment où les personnes concernées voient que le travail se fait avec elles.
Vient la hiérarchisation, qui consiste surtout à renoncer. Une organisation qui décide de tout traiter en même temps ne traite rien : les équipes ne peuvent absorber qu'un nombre limité de changements simultanés sans que la qualité baisse. Les critères de choix sont la fréquence de l'étape concernée, la gêne réellement ressentie par ceux qui la subissent, les dépendances — certaines étapes doivent être corrigées avant d'autres, qui reposent dessus — la réversibilité, et le caractère observable du résultat. L'irritant le plus bruyant n'est pas toujours le premier à traiter : un premier chantier modeste, visible et peu risqué crée le crédit nécessaire pour aborder ensuite les sujets qui touchent aux rôles.
La simplification précède l'outillage, et cet ordre n'est pas négociable. On supprime les étapes qui n'existaient plus que par habitude, on fusionne les formulaires qui demandent la même chose, on écrit les règles de validation restées implicites, on décide pour chaque type d'information un endroit unique. Le processus ainsi allégé devient le cahier des charges. Confronté aux outils, il permet de poser les bonnes questions : ce produit sait-il faire ce que nous faisons, et à quel prix en contorsions ? Un logiciel impose toujours une façon de travailler ; le choix consiste à savoir laquelle de ses contraintes on accepte sciemment, plutôt qu'à la découvrir après le déploiement. La réponse la moins spectaculaire — garder l'outil en place et en changer l'usage — reste souvent défendable.
Le déploiement se fait sur un périmètre réel mais restreint : une équipe, un type de dossier, une étape. On définit à l'avance ce qui vaudra confirmation, ce qui vaudra alerte, et à quelle condition on revient en arrière — décider cela d'avance évite de le décider sous tension. Une période où l'ancienne et la nouvelle façon de faire coexistent est parfois nécessaire, à condition qu'elle soit voulue, bornée par une condition de sortie écrite, et non subie. Pendant cette phase, on documente le processus tel qu'il se stabilise plutôt qu'après coup, quand plus personne ne se souvient des raisons d'un choix.
L'accompagnement des équipes se poursuit après le démarrage, période où l'essentiel se joue. La formation porte sur les cas réels du métier et non sur les menus du logiciel, en commençant par les situations inconfortables : que fait-on quand le cas ne rentre dans aucune case prévue, à qui s'adresse-t-on, comment signale-t-on que quelque chose ne va pas. Un référent interne identifié vaut mieux qu'une adresse anonyme, et il faut revenir voir l'équipe une fois la nouveauté passée, car c'est à ce moment que les contournements réapparaissent. Un chantier se termine à trois conditions : la nouvelle procédure est écrite, l'ancienne est explicitement retirée, et quelqu'un est désigné pour la maintenir. Tant que les deux façons de faire coexistent sans décision, les données se séparent en silence.
Les manières de rater un changement numérique
En résumé : Outiller avant d'avoir compris le processus, réduire la formation à une démonstration le jour du démarrage, empiler des logiciels qui ne se parlent pas, décider sans ceux qui font le travail, et ne jamais arrêter l'ancienne méthode.
La première erreur consiste à choisir l'outil avant d'avoir décrit le processus. Elle produit deux issues, toutes deux coûteuses. Ou bien le travail se déforme pour entrer dans les hypothèses du logiciel, sans que personne n'ait choisi cette réorganisation : elle s'impose par défaut, on la découvre en la subissant. Ou bien le produit est adapté à coups de développements spécifiques jusqu'à reproduire fidèlement le désordre antérieur, à un coût supérieur et avec une dépendance en prime. Le signe le plus fiable que cette erreur a été commise apparaît quelque temps après le démarrage : des tableurs parallèles réapparaissent. Ils signifient que l'outil ne couvre pas un cas réel et que l'équipe a réparé le manque en silence, sans le dire, parce que le projet était officiellement une réussite.
La deuxième est de réduire la formation à une démonstration au moment du démarrage. Une démonstration montre les écrans dans l'ordre confortable, à des gens qui n'ont pas encore de dossier urgent en attente. Ce dont une équipe a besoin est différent : voir ses propres cas traités, en particulier les cas pénibles, et savoir quoi faire quand l'outil ne sait pas faire. L'autre variante du même problème consiste à former une personne référente à charge pour elle de former les autres. La connaissance se concentre alors sur une seule tête ; le jour où cette personne s'absente ou quitte l'entreprise, le processus part avec elle. Écrire la procédure et faire pratiquer plusieurs personnes coûte peu et évite exactement cela.
La troisième est l'empilement d'outils qui ne communiquent pas. Chaque besoin trouve sa réponse séparément, chaque produit est bon isolément, et personne ne décide de l'ensemble. Les personnes deviennent alors l'interface entre les logiciels : elles recopient d'un écran à l'autre, elles arbitrent entre deux versions contradictoires d'une même donnée, elles savent laquelle est à jour parce qu'elles s'en souviennent. Le coût des abonnements se voit sur une facture ; le coût de cette coordination ne se voit nulle part et il augmente à chaque ajout. Avant d'introduire un outil supplémentaire, deux questions valent d'être posées : que remplace-t-il, et comment se relie-t-il à ce qui reste ? Un outil qui ajoute un endroit à consulter sans en supprimer un autre ajoute du travail.
La quatrième tient à la manière dont la décision est prise et annoncée. Un changement conçu loin de ceux qui font le travail repose sur une description fausse du processus, et il est reçu comme un soupçon d'inefficacité — ce qui suffit à produire un rejet poli et durable. Quatre points méritent d'être posés explicitement avant le premier déploiement : le problème que l'on cherche à résoudre et à quoi on saura qu'il l'est, le périmètre touché à cette étape et celui qui ne l'est pas encore, la manière dont les difficultés rencontrées doivent remonter et à qui, et la personne qui tranche lorsque deux services ne sont pas d'accord. S'y ajoute un choix de calendrier trop souvent négligé : lancer un changement pendant la période la plus chargée de l'activité garantit que personne n'aura la disponibilité mentale de l'apprendre, et transforme une difficulté normale en échec attribué à l'outil.
La cinquième est de ne jamais arrêter l'ancienne méthode, et de n'avoir noté nulle part l'état initial. Tant que les deux systèmes coexistent sans décision, les informations se répartissent entre eux au gré des préférences individuelles et aucun des deux n'est complet ; l'organisation se retrouve moins fiable qu'avant d'avoir commencé. Quant à l'état initial, s'il n'a pas été décrit — combien d'endroits il fallait consulter pour répondre à une question courante, quelles étapes obligeaient à redemander une information déjà fournie, ce dont les équipes se plaignaient spontanément — la discussion sur les résultats se réduira à des impressions contradictoires. Ces deux oublis se rejoignent dans un troisième : le chantier sans fin définie, qui glisse dans un paramétrage permanent que plus personne n'ose interrompre.
Quand un accompagnement au changement numérique n'est pas la bonne réponse
En résumé : Une organisation en crise doit d'abord se stabiliser ; une très petite équipe gagne souvent plus à supprimer des étapes qu'à ajouter un outil ; et aucune fluidité interne ne rattrape une offre qui ne trouve pas preneur.
Le premier cas est celui de l'organisation en crise. Une trésorerie tendue, un conflit interne non réglé, une échéance réglementaire imminente, le départ de la personne qui tenait seule un pan de l'activité : ces situations réclament exactement ce qu'un changement consomme, c'est-à-dire de l'attention, de la disponibilité et une tolérance à une dégradation temporaire des performances. Or tout changement dégrade avant d'améliorer, parce que les automatismes acquis cessent de servir pendant la période d'apprentissage. Lancer une transformation à ce moment revient à demander un effort supplémentaire à une équipe déjà à découvert. La séquence honnête est inverse : stabiliser d'abord, y compris par des mesures grossières et provisoires, puis transformer quand l'organisation dispose à nouveau d'une marge.
Le deuxième cas est celui de l'équipe très réduite. Une bonne part de la valeur d'un outil de gestion tient à la coordination : il permet à des personnes qui ne se parlent pas de partager un état commun. Dans une équipe où tout le monde sait ce que font les autres, ce bénéfice est faible, tandis que les coûts restent entiers — un abonnement, une administration à assurer, une nouvelle chose à tenir à jour, un endroit de plus où chercher. Le gain se trouve alors ailleurs : supprimer des étapes, réduire le nombre d'endroits où l'information est écrite, arrêter de produire un état que personne ne lit, unifier deux fichiers en un. Ces changements ne se vendent pas bien, ils ne s'affichent pas sur une page d'accueil, et ils rendent souvent davantage. L'outillage devient pertinent plus tard, quand l'effectif augmente ou qu'il faut pouvoir remplacer quelqu'un.
Le troisième cas est celui où le problème n'est pas dans le processus. Un changement numérique rend une organisation plus efficace à faire ce qu'elle fait déjà ; il ne dit rien de la pertinence de ce qu'elle fait. Si le produit ne rencontre pas son marché, si la marge est structurellement insuffisante, si les clients partent pour une raison qui tient à l'offre, améliorer la circulation interne des informations accélère la marche vers le même mur. Le diagnostic doit donc distinguer une entreprise ralentie par ses processus d'une entreprise en difficulté commerciale qui attribue à ses outils une cause qui est ailleurs. La confusion est fréquente et compréhensible, parce que le processus est un objet réparable, alors que l'autre question est douloureuse.
Le quatrième cas tient à la disponibilité de la décision. Un chantier de cette nature soulève des arbitrages qu'aucun prestataire ne peut trancher à la place de l'entreprise : qui valide désormais, quelle exception cesse d'être traitée, quelle règle devient opposable. Si personne n'a le mandat de décider, ou si les personnes qui l'ont ne peuvent pas dégager le temps nécessaire, le travail s'arrête au stade du diagnostic et produit un document que personne n'appliquera. Il en va de même pour les équipes saturées : la disponibilité à apprendre est une ressource au même titre que le budget, et elle se réserve avant de commencer. Mieux vaut reporter que produire un rapport de plus.
Le cinquième cas est une question de moment. Un changement se justifie par un déclencheur : une croissance qui rend la coordination informelle impraticable, le départ prévisible de la personne qui détient un savoir non écrit, une obligation nouvelle, un volume qui ne passe plus. En l'absence de déclencheur, une organisation qui fonctionne peut légitimement décider de continuer ainsi, et ce n'est pas un retard. La question utile n'est donc pas de savoir si une entreprise est en avance ou en retard, mais si quelque chose la gêne assez pour justifier l'effort. Quand la réponse est non, le dire fait partie du travail, et se donner rendez-vous quand la situation aura changé vaut mieux qu'un chantier lancé pour ne pas rester immobile.
Questions fréquentes
Un changement numérique implique-t-il forcément de nouveaux logiciels ?
Non, et c'est souvent l'inverse qui se produit. Une part importante des gains vient de la suppression d'étapes devenues inutiles, de la décision d'un endroit unique pour chaque type d'information, ou de l'activation de fonctions déjà comprises dans un outil en place et jamais utilisées. Le logiciel devient nécessaire quand le processus simplifié dépasse ce que les outils existants savent porter — pas avant. Commencer par l'achat revient à répondre à une question qui n'a pas encore été posée.
Par où commencer quand tout semble à reprendre ?
Par une seule chose, choisie pour de bonnes raisons. On décrit d'abord le processus le plus fréquent, celui qui touche le plus de dossiers, parce que c'est là que les frictions se répètent. On choisit ensuite un premier chantier modeste, visible et réversible, dont on saura dire s'il a marché. Traiter tout en même temps garantit l'inverse du résultat recherché : l'attention disponible se disperse, aucun chantier ne va assez loin pour produire un effet visible, et l'organisation conclut que rien ne marche. Un premier chantier mené jusqu'au bout rend le suivant nettement plus facile à faire accepter.
Faut-il un référent interne, et que fait-il exactement ?
Oui, et son rôle est plus large qu'il n'y paraît. Il n'est pas le spécialiste du logiciel mais le point de contact de l'équipe : il recueille les irritants, distingue ce qui relève d'un manque de formation de ce qui relève d'un défaut de conception, et fait remonter les cas non prévus. Il doit être disponible, connu de tous et reconnu par la direction. En revanche, il ne doit pas être le seul à savoir : la connaissance doit être écrite et pratiquée par plusieurs personnes, sinon son absence bloque le processus.
Comment faire quand une partie de l'équipe s'y oppose ?
En écoutant l'objection avant d'y répondre, car elle est souvent exacte. Une opposition signale fréquemment un cas réel que le nouveau processus ne couvre pas, ou une charge supplémentaire qui n'a pas été vue. Trois leviers fonctionnent : faire participer les intéressés à la description du processus, dire explicitement ce qui ne change pas, et montrer un bénéfice pour la personne elle-même et pas seulement pour l'organisation. Ce qui ne fonctionne pas, c'est de traiter le refus comme un problème de communication à corriger par une réunion supplémentaire.
Que deviennent les tableurs et les fichiers existants ?
Ils méritent un examen plutôt qu'un abandon. Un tableur qui tient une activité contient des règles métier qui n'ont jamais été écrites ailleurs : c'est une source de documentation précieuse. La reprise des données pose ensuite trois questions distinctes : ce qui est repris, ce qui est archivé sans être repris, et ce qui est abandonné parce qu'il n'a plus d'usage. Reprendre l'intégralité d'un historique douteux importe les erreurs dans le nouvel outil et fait perdre la confiance dès le premier jour d'usage.
Vaut-il mieux un outil unique ou plusieurs outils spécialisés ?
Cela dépend de la quantité d'informations qui doivent circuler entre les étapes. Un outil unique simplifie la cohérence des données et l'administration, au prix de fonctions moyennes partout. Des outils spécialisés font mieux chacun dans son domaine, mais le coût se déplace vers les liaisons entre eux et vers les personnes qui les assurent. Le critère de décision est donc l'interopérabilité réelle, pas la richesse fonctionnelle : un produit excellent qui ne laisse pas sortir ses données finit par contraindre tout le reste de l'organisation.
Comment éviter de se retrouver prisonnier d'un éditeur ?
En traitant la sortie comme un critère de choix et non comme une hypothèse désagréable. Trois vérifications avant de s'engager : les données peuvent-elles être exportées dans un format lisible sans l'outil, la configuration est-elle documentée ailleurs que dans la mémoire d'une personne, et le processus reste-t-il compréhensible indépendamment du produit. Il faut aussi vérifier qui administre l'outil au quotidien : lorsque cette compétence est entièrement externalisée, la dépendance porte sur le prestataire autant que sur le logiciel.
À quoi voit-on qu'un changement a réellement servi ?
À des signes observables, choisis et relevés avant de commencer. Selon les cas : le nombre d'endroits à consulter pour répondre à une question courante, le nombre de fois où une même information est saisie, le temps qui sépare l'arrivée d'une demande de sa prise en charge effective, la capacité à répondre à un client sans consulter un collègue, la facilité avec laquelle une personne reprend un dossier commencé par quelqu'un d'autre. On observe aussi l'usage réel du nouveau processus : la réapparition de fichiers parallèles est le signal le plus fiable qu'un cas n'est pas couvert.
Comment sait-on qu'un chantier est terminé ?
Un chantier n'est pas terminé quand l'outil est installé, mais quand trois conditions sont réunies : la nouvelle procédure est écrite et accessible, l'ancienne est explicitement retirée plutôt que laissée en parallèle, et une personne est désignée pour maintenir l'ensemble. Sans ce point d'arrêt, le projet se prolonge en réglages indéfinis et l'organisation s'habitue à vivre en travaux. La transformation d'une organisation n'est pas un état continu : c'est une succession de chantiers qui commencent et qui se terminent.
Peut-on mener ce travail en interne, sans regard extérieur ?
Oui, et beaucoup d'organisations le font. Le regard extérieur apporte deux choses difficiles à obtenir de l'intérieur : il pose les questions naïves que personne n'ose plus poser, et il n'a pas d'intérêt dans les arbitrages entre services. En revanche, il ne détient pas la connaissance du métier, qui reste chez ceux qui l'exercent. Un accompagnement qui prétendrait décider à la place de l'équipe produirait une description théorique du travail, c'est-à-dire précisément le document que personne n'applique.