Numériser n'est pas automatiser : pourquoi un projet passe la recette sans produire aucun effet
Il existe un signe fiable pour repérer un projet qui passera la recette sans produire aucun effet. Le rapport de résultats ne mentionne aucune règle qui aurait changé : il énumère les modules déployés, les utilisateurs formés, les données migrées et la part des processus « couverts par le système ». Pas une ligne sur ce qui se fait désormais autrement.
Un tel projet ne trompe personne délibérément. Il rend compte honnêtement de ce qu'il a fait : le travail est passé du papier et des tableurs à une interface. Le problème, c'est que ce déménagement, en soi, ne change ni la charge de travail ni le taux d'erreur — il ne fait que déplacer l'endroit où ils apparaissent.
La numérisation déplace le travail vers un environnement numérique ; l'automatisation supprime le travail lui-même. Une seule question permet de les distinguer : quelle règle a changé ? Si la réponse est aucune, l'effet sera nul, voire négatif — les mesures effectuées dans le secteur de la santé montrent que le passage à des systèmes électroniques sans réingénierie des processus fait augmenter la part du temps administratif au lieu de la réduire.
Quatre signes qu'une numérisation se fait passer pour une automatisation
Les quatre signes sont visibles dès la phase de recette et ne demandent aucune expertise particulière. Il suffit de lire le rapport de projet et de lui poser quatre questions — un exercice qu'une direction financière ou un responsable de processus peut mener en vingt minutes, sans même ouvrir un écran du système.
Le rapport n'est composé que de substantifs. Déployé, paramétré, formé, migré. L'automatisation, elle, se décrit avec des verbes de disparition : « le calcul ne se fait plus manuellement », « la validation n'est plus nécessaire », « le champ n'a plus besoin d'être renseigné ». Si ce type de formulation manque au rapport, le travail sous-jacent n'a nulle part disparu — il a simplement changé d'adresse.
Le nombre d'étapes du processus n'a pas changé. Il y avait neuf étapes avant le projet, il y en a toujours neuf après, simplement exécutées dans le système plutôt que sur papier. C'est le signe le plus fiable de tous : une automatisation véritable réduit toujours le nombre d'étapes, car une étape disparaît dès que son résultat commence à être calculé selon une règle plutôt qu'exécuté par une personne.
De nouvelles actions obligatoires sont apparues. Cocher un statut, poser un indicateur, dupliquer une saisie dans un système voisin. Chacune de ces actions constitue un travail nouveau, qui n'existait pas avant le projet, et il retombe en pratique le plus souvent sur la personne même dont le projet devait alléger la charge — le gestionnaire de dossier, le chargé de compte, celui qui clôture le dossier.
L'effet se mesure au taux de couverture. « Quatre-vingts pour cent des demandes passent désormais par le système » est un indicateur de déploiement, pas un indicateur de résultat. Il progresse dans tous les scénarios, y compris celui où le temps de traitement d'un dossier a doublé sans que personne ne s'en aperçoive, faute d'avoir jamais mesuré ce temps de traitement au départ.
| Signe | Ce qu'il signifie | Question à poser |
|---|---|---|
| Le rapport n'est composé que de substantifs | Aucune règle n'a changé | Qu'est-ce qui se fait désormais autrement ? |
| Le nombre d'étapes est inchangé | Le travail a déménagé, il n'a pas disparu | Quelle étape a cessé d'exister ? |
| De nouvelles actions obligatoires sont apparues | Du travail a été ajouté, pas retiré | Qui les exécute, et qu'obtient-il en retour ? |
| L'effet est mesuré par le taux de couverture | Le résultat réel n'a jamais été mesuré | Combien de temps prend un dossier aujourd'hui ? |
C'est en général la dernière question qui met le problème au jour : aucune mesure de temps n'a été prise avant le déploiement, il n'y a donc rien pour y répondre, et la conversation se replie discrètement sur le taux de couverture.
Une distinction formulée il y a trente-cinq ans
Le sujet n'est pas nouveau, et sa formulation la plus juste précède de plusieurs décennies les logiciels d'entreprise actuels — bien avant qu'on ne vende une plateforme, un portail ou un copilote d'intelligence artificielle.
Dans le cas décortiqué par l'auteur, une entreprise prévoyait d'automatiser le traitement des paiements fournisseurs et de réduire les effectifs du service de 20 %. Après réingénierie du processus lui-même — le nombre de postes à rapprocher au moment du paiement est passé de 14 à 3, et le rapprochement avec la facture a été purement et simplement supprimé — la réduction effective a atteint 75 %.
La limite est réelle, et je la nomme moi-même : ce n'est pas une étude, c'est un article de management appuyé sur des cas, et les chiffres n'ont jamais été audités de façon indépendante. La valeur se trouve ailleurs — dans la précision de la distinction qu'il établit. L'écart entre une réduction de 20 % et une réduction de 75 % ne vient pas d'un meilleur système. Il vient de la décision de vérifier trois postes au lieu de quatorze. C'est une décision de processus, et une entreprise aurait pu la prendre avec un crayon et une note de service, sans le moindre logiciel.
Ce que montrent les mesures dans le secteur de la santé
La santé est l'un des rares domaines où le passage aux systèmes électroniques a été mesuré non par sondage, mais par journaux d'événements et chronométrage direct, sur de larges échantillons et dans la durée. Les conclusions se transposent bien à tout secteur où un document fait foi — assurance, banque, logistique, services professionnels.
Les médecins passaient 355 minutes (5,9 heures) dans le dossier patient informatisé sur une journée de travail de 11,4 heures, dont 157 minutes — 44,2 % de leur temps dans le système — consacrées à des tâches administratives plutôt qu'aux patients.
Une seule spécialité, un seul système de santé universitaire, un seul éditeur de logiciel — une généralisation directe à d'autres secteurs appelle la prudence. Mais la méthode est solide : non pas de l'auto-déclaration, mais des journaux d'événements recoupés par un chronométrage direct. C'est exactement le type de mesure qui manque aux projets d'entreprise, où l'effet est évalué au taux de couverture faute de mieux.
Un résultat encore plus convaincant provient d'une étude qui compare directement la version papier et la version électronique d'un même travail.
Les internes en médecine passaient 73,0 % de leur temps sur des tâches sans lien direct avec le patient, contre seulement 17,9 % consacrées aux soins directs. Chez les utilisateurs du dossier patient informatisé, la part du temps administratif était plus élevée que chez leurs collègues travaillant encore sur papier : 44,1 % contre 37,3 %.
La répartition du temps a ici été relevée par déclaration des participants et non par journaux système — une limite réelle — et l'échantillon se restreint au personnel médical junior d'un seul pays. Le sens du résultat n'en va pas moins directement à l'encontre de ce que la numérisation est censée produire : la part du temps administratif est plus élevée chez les utilisateurs du dossier électronique, pas plus faible. Le format électronique n'a supprimé aucune exigence — il a simplement rendu leur respect plus coûteux en temps.
Pourquoi la situation empire avec le temps, au lieu de s'améliorer
Le second fait contre-intuitif : la charge de travail dans un système numérique fonctionnant selon des règles inchangées augmente avec le temps, et elle ne se stabilise pas d'elle-même.
Sur quatre ans, le temps total passé par un médecin dans le système électronique pour une journée de consultation de huit heures a augmenté de 28,4 minutes (+7,8 %) : le temps consacré à la saisie des prescriptions a augmenté de 58,9 %, et celui consacré au traitement des messages entrants de 24,4 %.
La période recoupe en partie la reprise de la charge de travail post-pandémie, ce qui peut amplifier quelque peu la tendance observée — cette réserve doit être posée clairement. Le mécanisme sous-jacent reste néanmoins facile à suivre et se reproduit partout : dans un système qui n'élimine jamais une exigence, chaque nouvelle exigence vient simplement s'ajouter aux précédentes. Les règles s'accumulent pour une raison banale — ajouter un champ coûte moins cher, et est politiquement bien moins compliqué, que d'en supprimer un.
Comment distinguer les deux avant de démarrer un projet
La deuxième étape exige une personne dotée du pouvoir de supprimer une étape, et c'est là le véritable obstacle organisationnel, non technique. Un prestataire ne détient pas ce pouvoir. La direction informatique, en général, ne le détient pas non plus. Tant que le responsable de processus n'a pas tranché en faveur de la suppression d'une étape, tout projet se réduit par défaut à un déménagement — c'est exactement le point que je développe dans un article consacré à pourquoi il faut corriger le processus avant de déployer le système.
Quatre questions à poser à tout rapport de déploiement
Quelle étape a cessé d'exister
Pas « est devenue plus rapide » — réellement disparue. S'il n'y en a aucune, tout effet observé ne viendra que du déménagement lui-même.
Quelle règle a changé
Combien de postes sont rapprochés, qui valide, qu'est-ce qui n'a plus besoin d'être renseigné. Une règle, c'est ce qui était obligatoire hier et ne l'est plus aujourd'hui.
Combien de nouvelles actions sont apparues
Indicateurs, statuts, saisies dupliquées dans des systèmes voisins. Leur somme vient se soustraire à l'effet annoncé.
Combien de temps prend un dossier aujourd'hui
Minutes par résultat, mesurées avant et après. Le taux de couverture par l'interface n'est pas une réponse à cette question, quelle que soit la façon dont on la formule.
Si le rapport de résultats du déploiement ne recense aucune étape supprimée, vous avez payé le déménagement du travail — pas sa réduction.
Questions fréquentes
Quelle est la vraie différence entre numérisation et automatisation ?
La numérisation déplace le travail vers un environnement numérique tout en conservant son volume : mêmes étapes, mêmes validations, mêmes champs à remplir — simplement à l'écran plutôt que sur papier. L'automatisation supprime le travail : une étape cesse d'être exécutée parce que son résultat est désormais calculé selon une règle, ou parce qu'elle n'est plus requise du tout. Il existe un critère unique pour distinguer les deux : le nombre d'étapes du processus a-t-il changé ?
La numérisation peut-elle être utile en soi, sans automatisation ?
Oui, mais pour des raisons différentes de celles habituellement mises en avant : les données deviennent exploitables pour l'analyse, le travail cesse de dépendre de la présence physique d'une personne donnée, un historique des modifications apparaît là où il n'existait pas. Ce sont des bénéfices réels et légitimes, qu'il vaut mieux nommer clairement pour ce qu'ils sont. L'erreur survient quand la numérisation est vendue comme une réduction de charge de travail — un an plus tard, il faut expliquer au responsable budgétaire pourquoi la charge administrative n'a pas bougé.
Pourquoi la charge de travail augmente-t-elle après le déploiement d'un système, au lieu de diminuer ?
Parce que le format numérique rend possible l'ajout d'exigences qui auraient été impraticables sur papier : champs obligatoires supplémentaires, indicateurs de statut, saisies dupliquées dans des systèmes voisins à des fins de reporting. Aucune des anciennes exigences n'est supprimée pour autant — supprimer une exigence coûte plus cher, et est politiquement bien plus délicat, qu'en ajouter une nouvelle. C'est ainsi que la charge s'accumule discrètement, et les mesures effectuées dans le secteur de la santé montrent précisément cette accumulation dans la durée.
Qui doit prendre la décision de supprimer une étape ?
Le responsable du processus — la personne qui répond de son résultat, et non celle qui dirige le projet par ailleurs. Ni le prestataire ni la direction informatique ne détiennent ce pouvoir, et aucun des deux ne devrait le détenir : supprimer une étape revient à accepter un risque, et ce risque doit être porté par celui qui répond du résultat. Si aucune personne dans le projet ne peut affirmer « ce contrôle, nous ne le faisons plus », le projet se réduira par défaut à un déménagement, quelle que soit la formulation du cahier des charges.
La liste des quatre signaux d'alerte et l'ordre des questions à poser à un rapport de déploiement constituent une synthèse propre à l'auteur, tirée des déploiements de CRM et de produits maison chez Alego.Digital, ainsi que de la pratique de recette sous le référentiel interne de relation client. Aucune métrique interne n'est citée dans cet article : chaque chiffre mentionné provient d'une source externe dont la méthode est précisée. Il n'existe pas de description formalisée de ce contrôle dans les documents de l'entreprise.
- Hammer M. Reengineering Work: Don't Automate, Obliterate. Harvard Business Review, juillet–août 1990. hbr.org
- Arndt B. G. et al. Tethered to the EHR: Primary Care Physician Workload Assessment. Annals of Family Medicine, septembre 2017. annfammed.org
- Arab S. et al. Time Allocation in Clinical Training (TACT). QJM: An International Journal of Medicine, octobre 2025. academic.oup.com
- Arndt B. G., Micek M. A., Rule A. et al. Longitudinal Analysis of EHR Use, 2019–2023. Annals of Family Medicine, janvier 2024. annfammed.org