Le diagnostic de terrain consiste à observer le travail là où il se fait, avec ceux qui le font, avant de concevoir quoi que ce soit. Il décide du succès d'un projet digital parce qu'il révèle l'écart entre la procédure écrite et la pratique réelle. Un logiciel bâti sur la procédure écrite sera contourné ; un logiciel bâti sur la pratique réelle sera utilisé.
Qu'est-ce qu'un diagnostic de terrain ?
C'est une période d'immersion dans l'organisation. L'équipe chargée du projet se rend dans les services, les agences, les entrepôts ou les centres concernés. Elle suit des dossiers du début à la fin, s'assoit à côté des agents, regarde les registres, les tableurs, les formulaires papier et les groupes de messagerie qui servent réellement à faire tourner l'activité.
Le diagnostic ne se confond pas avec un audit. Un audit vérifie la conformité à une règle. Le diagnostic cherche à comprendre pourquoi les choses se font ainsi, sans jugement. La double saisie que tout le monde critique existe souvent pour une bonne raison : un contrôle que le système actuel ne sait pas faire, une information qu'un autre service réclame, une coupure de réseau qui a un jour fait perdre une journée de travail.
Que regarde-t-on pendant un diagnostic ?
Quatre familles d'éléments sont passées en revue. Chacune oriente des décisions de conception précises.
| Ce que l'on observe | Ce que cela détermine |
|---|---|
| Le parcours réel d'un dossier, d'un produit ou d'un usager | Les étapes, les validations et les états que la solution devra gérer |
| Les outils parallèles : cahiers, tableurs, messages | Les besoins non couverts par les outils officiels |
| L'environnement physique : réseau, électricité, chaleur, poussière, affluence | Le mode déconnecté, le type de matériel, l'ergonomie des écrans |
| Les personnes : rôles, ancienneté, aisance avec le numérique | Les profils d'accès, le plan de formation, le rythme de déploiement |
| Les données existantes et leur qualité | L'effort de reprise et de nettoyage avant la mise en service |
On regarde aussi les moments de tension : la fin de mois, le jour de marché, la rentrée, la période de paie. Un outil qui convient un mardi calme peut devenir inutilisable quand la file s'allonge devant le guichet. C'est à ces moments que les agents reviennent au papier, et c'est donc pour ces moments qu'il faut concevoir.
Pourquoi les entretiens en salle de réunion ne suffisent-ils pas ?
En réunion, chacun décrit le fonctionnement prévu. Ce n'est pas de la mauvaise foi : la version officielle est celle que l'on connaît par cœur et que l'on se sent autorisé à exposer. Les exceptions, les arrangements et les astuces, qui représentent une part importante du travail quotidien, ne sont pas mentionnés parce qu'ils semblent trop évidents ou trop peu avouables.
Les réunions réunissent en outre rarement les bonnes personnes. Ceux qui y participent sont les responsables. Ceux qui saisissent, contrôlent et relancent sont restés à leur poste. Or ce sont eux qui utiliseront l'outil plusieurs heures par jour et qui savent exactement où il perdra du temps. La préparation d'un diagnostic gagne d'ailleurs à s'appuyer sur un premier travail interne : si vous n'avez jamais formalisé vos circuits, commencez par cartographier vos processus, même sommairement.
Un cas typique : le cahier que personne n'avait mentionné
Dans un entrepôt de distribution, la direction souhaite informatiser les sorties de stock. Les réunions décrivent un circuit net : bon de commande, préparation, bon de sortie signé, mise à jour du stock. Sur place, le chef magasinier tient pourtant un cahier personnel, rangé dans un tiroir. Il y note les sorties « provisoires » : des marchandises remises en urgence à un commercial, régularisées plus tard, parfois jamais.
Ce cahier n'apparaissait dans aucune procédure, et il expliquait à lui seul l'essentiel des écarts d'inventaire. La solution a donc été conçue avec un statut de sortie en attente de régularisation, visible par la direction, avec relance automatique. Sans la visite, le logiciel aurait reproduit le circuit officiel, et le cahier aurait continué d'exister à côté.
Un outil parallèle n'est jamais un caprice. C'est la trace d'un besoin que le système en place ne couvre pas.
Que doit contenir la restitution d'un diagnostic ?
Un diagnostic qui se termine par un document de cent pages que personne ne lit n'a servi à rien. La restitution doit être présentée aux équipes, discutée, corrigée, et tenir en quelques éléments utiles :
- une description des circuits tels qu'ils fonctionnent aujourd'hui, validée par ceux qui les font vivre ;
- la liste des irritants et des risques, classés par gravité et par fréquence ;
- les contraintes du site qui s'imposent à toute solution ;
- une proposition de périmètre et d'ordre de déploiement : par quel service commencer et pourquoi ;
- les décisions que la direction doit prendre avant le développement, par exemple sur une règle de gestion appliquée différemment d'une agence à l'autre.
Ce dernier point est souvent sous-estimé. Le diagnostic met au jour des questions d'organisation qu'aucun logiciel ne peut trancher à la place des dirigeants. Mieux vaut les traiter à ce stade qu'en plein déploiement.
Que risque-t-on à s'en passer ?
Le projet démarre plus vite, et c'est son seul avantage. Les incompréhensions apparaissent ensuite une à une : un champ obligatoire que l'agent ne peut pas renseigner, une application qui exige le réseau là où il n'y en a pas, un matériel qui ne tient pas une journée de tournée. Chaque correction arrive alors que le logiciel est déjà construit, donc au moment où elle est la plus difficile à intégrer.
Chez Linking Development, le diagnostic sur site est la première des sept étapes de chaque projet, et la phase suivante, où les écrans sont ajustés en présence des équipes, n'a de sens que parce qu'elle s'appuie sur lui.
Vous envisagez de digitaliser un service ou l'ensemble de votre activité ? Parlons de votre contexte avant de parler de fonctionnalités.