Un outil métier PME qui va chercher les données lui-même : retour sur un projet réel

Quatre outils, une tâche, et 80 % du temps perdu en chemin

La PME gère des contrats pour ses clients. Une quinzaine de personnes, un back-office maison développé au fil des années, des tableurs pour les cas particuliers, une messagerie pour les échanges avec les partenaires externes, un outil de stockage cloud pour les documents contractuels. Rien d'exceptionnel : c'est la configuration de beaucoup de PME de services qui ont grandi sans refonte globale de leur système d'information.

Le problème est apparu lors d'un atelier de cartographie des processus. Pour remplir un formulaire sur une plateforme réglementaire externe, les opérateurs devaient successivement ouvrir le back-office pour récupérer les données du contrat, ouvrir la messagerie pour retrouver un échange récent avec le partenaire, ouvrir le tableur pour vérifier une valeur spécifique, puis ouvrir le stockage cloud pour confirmer une référence documentaire. Quatre systèmes. Une seule tâche.

La mesure était précise : quatre minutes de collecte d'information pour une minute d'exécution réelle sur la plateforme. L'équipe l'a formulé lors de l'atelier avec une clarté qui résume le problème mieux que n'importe quelle analyse :

« La consolidation des données, ça représente 80 % du temps de la tâche. »

Ce ratio, 80 % de collecte pour 20 % d'exécution, est la signature d'un système d'information fragmenté. Les données existent, elles sont à jour, elles sont correctes. Mais elles sont dispersées entre des outils qui ne communiquent pas entre eux. L'humain compense cette absence de connexion en jouant le rôle de pivot d'information, naviguant de système en système pour assembler ce dont il a besoin.

Si vous vous retrouvez dans cette description, le diagnostic de vos données avant d'automatiser est l'étape qui permet de quantifier précisément ce que vous perdez.

Pourquoi automatiser en premier aurait été une erreur

La réaction naturelle face à ce constat est d'automatiser. Si la collecte prend 80 % du temps, automatisons la collecte. C'est une intuition compréhensible, et elle conduit à des projets qui coûtent cher pour des résultats décevants.

Dans ce cas précis, l'analyse des dossiers traités sur les six derniers mois a révélé que 40 % des contrats comportaient des champs personnalisés qui sortaient du processus standard. Des particularités liées à des accords spécifiques, des historiques clients, des conditions négociées au cas par cas. Ces cas particuliers n'étaient documentés nulle part de manière structurée. Ils vivaient dans la mémoire des opérateurs expérimentés, dans des échanges de mails, dans des notes dans des tableurs personnels.

Automatiser sur cette base aurait signifié coder les exceptions autant que le processus nominal. Ou, pire, automatiser uniquement le processus standard et laisser les cas particuliers gérer encore plus manuellement qu'avant, parce que l'automatisation des cas courants aurait créé l'illusion d'un problème résolu alors que 40 % des dossiers restaient dans les mains des personnes les plus expérimentées.

Le vrai diagnostic, posé lors de l'atelier, était ailleurs : les données nécessaires à l'exécution de chaque tâche devaient d'abord exister de manière structurée et centralisée avant qu'on puisse envisager quoi que ce soit d'automatisé. Ce n'est pas un problème d'automatisation. C'est un problème de référentiel.

Ce qu'on a construit à la place

Le projet s'est déroulé en deux phases distinctes, avec une troisième phase planifiée pour plus tard.

Phase 1 : la centralisation. On a identifié les données les plus sollicitées sur l'ensemble des tâches récurrentes. Pas toutes les données de l'entreprise, pas un référentiel exhaustif. Les données qui revenaient dans 80 % des tâches du quotidien. Ces données ont été structurées dans un back-office sur mesure : un référentiel unique, accessible par toute l'équipe, avec des règles de mise à jour claires. Les cas particuliers, les 40 % de contrats avec des champs spécifiques, ont été documentés et intégrés dans ce référentiel sous forme de champs enrichis, pas traités comme des exceptions à gérer en dehors du système.

Phase 2 : le gestionnaire de tâches. Une fois le référentiel en place, on a construit un outil simple : quand un opérateur crée une tâche, le gestionnaire lit le référentiel et pré-renseigne automatiquement les champs correspondants. L'opérateur arrive sur un formulaire déjà rempli avec les données du contrat, de l'interlocuteur, des conditions spécifiques. Il vérifie, ajuste si quelque chose a changé, et exécute.

« On n'est pas là pour délivrer du code. Notre valeur, c'est la capacité à poser les bonnes questions, à structurer la manière d'avancer et à prendre les bonnes décisions. »

La distinction est importante : l'opérateur ne collecte plus. Il valide. Ce glissement de rôle, de collecteur d'information à validateur, est ce qui change concrètement l'expérience des équipes au quotidien. La charge cognitive liée à la navigation entre les systèmes disparaît. Seule reste la vigilance sur la justesse de ce qui est affiché.

Pour en savoir plus sur la méthode qui consiste à d'abord normaliser les données avant de construire des outils par-dessus, l'article sur la normalisation V0 avant automatisation détaille l'approche étape par étape.

Ce que ça a changé concrètement

Le ratio s'est inversé. Sur les tâches concernées, le temps de préparation est tombé à quasi zéro. L'exécution, qui prenait une minute, prend toujours une minute. Mais la collecte, qui prenait quatre minutes, ne prend plus que quelques secondes de vérification. Le gain n'est pas dans la vitesse d'exécution de la tâche, il est dans l'élimination du temps d'approche.

L'effet secondaire le plus significatif n'était pas prévu dans le brief initial : l'intégration des nouveaux membres de l'équipe est devenue beaucoup plus rapide. Avant le projet, apprendre « où chercher quoi » représentait une part substantielle du temps d'onboarding. Savoir qu'il fallait aller dans le back-office pour telle donnée, dans le tableur partagé pour telle autre, dans les archives de messagerie pour retrouver un contexte historique, tout cela s'apprenait par l'expérience accumulée. Avec le référentiel centralisé et le préremplissage automatique, cette connaissance tacite est devenue une connaissance explicite, incorporée dans l'outil. Un nouvel opérateur peut être opérationnel sur ces tâches en quelques heures plutôt qu'en plusieurs semaines.

L'effet tertiaire, celui qui motive la phase 3, est peut-être le plus stratégique : les données sont désormais suffisamment structurées et fiables pour qu'une automatisation progressive soit envisageable. Les tâches les plus répétitives, celles qui suivent un processus entièrement standard, pourraient aujourd'hui être déclenchées automatiquement sans intervention humaine. Ce n'était pas possible avant, parce que le référentiel n'existait pas. Ce sera possible demain, parce qu'il existe et parce que l'équipe a appris à le maintenir à jour.

Le séquençage a tout fait : centraliser d'abord, construire l'outil de tâches ensuite, automatiser en dernier.

Ce que cette approche n'est pas

Ce n'est pas un ERP. Un ERP couvre l'ensemble des fonctions de l'entreprise dans une logique intégrée, avec une complexité d'implémentation et un coût d'administration qui n'ont pas de sens pour une équipe de quinze personnes. Ce référentiel et ce gestionnaire de tâches sont ciblés sur un périmètre précis : les données les plus sollicitées dans les tâches opérationnelles quotidiennes. Pas plus.

Ce n'est pas non plus un outil SaaS de gestion de formulaires. Les outils SaaS génériques permettent de créer des formulaires et des workflows, mais ils ne s'intègrent pas avec le back-office maison de la PME pour aller y lire les données spécifiques au contrat ouvert. Il aurait fallu une saisie manuelle de toute façon, ou un connecteur coûteux à maintenir. La question à se poser sur le choix entre sur mesure et SaaS est traitée plus en détail dans cet article sur les critères pour choisir entre back-office sur mesure et SaaS.

Ce que c'est, précisément : un outil focused construit sur mesure pour résoudre un goulot d'étranglement identifié avec précision. Ni une refonte globale, ni une solution générique. Une trottinette qui fait ce dont l'équipe a besoin, pas une Ferrari qui couvre tous les cas théoriques.

La question à se poser n'est pas « quel outil acheter » ni « quoi automatiser en premier ». La question utile est : dans les tâches récurrentes de votre équipe, combien de minutes partent à collecter les informations nécessaires avant de pouvoir commencer à travailler ? Ce ratio est le point de départ. Si vous ne l'avez pas mesuré, mesurez-le sur trois tâches cette semaine.