Éviter la double saisie entre logiciels

Une société de services reçoit ses demandes par courriel, par messagerie instantanée et par téléphone. Trois canaux, deux boîtes partagées, un numéro. Chaque demande est lue, comprise, qualifiée, puis retapée à la main dans le logiciel métier d'exploitation qui gère ensuite le planning, l'affectation des ressources et la facturation. Le logiciel fait correctement son travail sur son périmètre. La demande, elle, a déjà vécu ailleurs avant d'y entrer, et c'est ce trajet initial que personne n'outille.

Le dirigeant de cette société énonce trois coûts, dans cet ordre.

1. La double saisie et ses erreurs. Une adresse recopiée à l'approximation près, un horaire décalé d'une heure, un chiffre inversé dans un numéro de téléphone. Ces erreurs sont invisibles au moment de la frappe et deviennent visibles le jour de l'exécution, quand elles coûtent le plus cher.
2. Les demandes qui restent sans réponse. Les sollicitations arrivent sur plusieurs canaux et plusieurs boîtes. Faute de point de collecte unique, certaines passent entre les mailles. Leur nombre est inconnu, ce qui est la partie gênante.
3. Le reporting impossible à consolider. Sa formule décrit le mécanisme mieux que n'importe quel schéma : « chacun ne voit que son périmètre ». Aucun des outils en place ne peut produire la vue d'ensemble, puisque aucun ne détient l'ensemble.

Combien coûte une ressaisie

Aucune source publique ne donne le coût d'une ressaisie dans votre logiciel, avec vos champs et vos habitudes. Les nombres qui suivent sont des ordres de grandeur, posés pour montrer la mécanique du calcul, et ils doivent être remplacés par les vôtres avant toute décision.

Une demande entrante comporte en général entre huit et vingt champs utiles : identité du client, contact, dates, lieux, quantités, contraintes particulières, référence d'origine. Reprendre cet ensemble dans un second outil, en relisant pour éviter la faute, demande deux à cinq minutes une fois la qualification faite. Retenons trois minutes.

À trente demandes par jour ouvré, cela représente une heure et demie par jour, autour de sept heures par semaine, un peu plus de trois cents heures par an. Environ un cinquième d'un temps plein consacré à une opération qui ne crée aucune information : la donnée existait déjà, sous forme lisible, dans le message d'origine.

Le taux d'erreur se prête mal à l'emprunt. Les moyennes qui circulent sur la saisie manuelle proviennent de contextes industriels sans rapport avec une demande commerciale de vingt champs, et les reprendre ici ne vous apprendrait rien. Le nombre à établir est local : sur le mois écoulé, combien de dossiers ont fait l'objet d'une correction d'adresse, d'horaire ou de contact après leur création. Ce comptage prend une demi-journée et vaut mieux que n'importe quelle moyenne empruntée.

Le troisième coût ne se compte pas en heures. Il se compte en demandes qui n'ont jamais reçu de réponse, et il se rapproche par deux mesures accessibles : le délai entre la réception et la première réponse, et le nombre de fils sans réponse dans chaque boîte à la fin du mois. Les deux se relèvent à la main sur un échantillon de deux semaines.

Pourquoi le problème dure

Un logiciel métier est bâti pour couvrir un domaine avec précision. L'éditeur borne ce domaine, le documente, l'améliore, et cette discipline est ce qui fait la qualité de l'outil. La contrepartie est mécanique : l'espace situé entre deux outils n'appartient à personne. Il ne figure dans aucun contrat, il n'a pas de responsable désigné, il n'apparaît sur aucune facture. La seule personne qui le tienne est celle qui fait la ressaisie, et son travail reste invisible tant qu'il est fait correctement.

S'y ajoute une raison commerciale, qu'il vaut mieux nommer que déplorer. Un éditeur a intérêt à élargir la couverture fonctionnelle de son produit, rarement à expliquer comment le faire cohabiter avec un produit voisin. Cela se traduit très concrètement au moment de demander un accès API : les éditeurs sérieux instruisent ces demandes et vérifient que le système appelant ne reproduira pas une fonction déjà présente chez eux. La position est défendable et elle dessine la frontière du possible. Un lien s'obtient lorsqu'il complète le logiciel appelé, et se refuse lorsqu'il en duplique une fonction. Une demande d'accès qui dit clairement ce qu'elle fait en amont et ce qu'elle laisse à l'éditeur passe beaucoup mieux qu'une demande générique.

La conséquence pratique est qu'il faut savoir, avant d'appeler l'éditeur, où s'arrête son outil et où commence le vôtre.

Trois façons de traiter le lien

1. La ressaisie disciplinée

Un point d'entrée humain unique, une adresse de réception unique, un format de saisie fixe, un accusé systématique. Le travail reste manuel, il devient régulier.

Cette approche suffit sous quelques demandes par jour, avec peu de champs, et une personne identifiée qui tient le poste. Ses limites sont connues : elle dépend d'une présence, une absence l'interrompt, et elle ne produit toujours aucune vue consolidée. Elle a l'avantage de ne rien coûter et de se mettre en place en une semaine, ce qui en fait un point de départ raisonnable quand le volume est encore faible.

2. L'export-import périodique

Un fichier sort d'un système, entre dans l'autre, à intervalle fixe. C'est le compromis le plus répandu, et il est souvent le bon.

Il convient aux données qui tolèrent un décalage : alimentation d'un référentiel client, reporting mensuel, écritures comptables, historique. Ses défauts apparaissent dès que la fraîcheur compte. Le fichier vieillit entre deux passages. Sans identifiant stable partagé, les doublons s'accumulent. Une correction faite d'un côté est écrasée au passage suivant. Et l'opération dépend de quelqu'un qui s'en souvienne le vendredi soir.

Règle de tri : si une information doit être exacte à l'heure près pour quelqu'un qui agit, l'export périodique ne tiendra pas. Pour ce qui se lit à la semaine ou au mois, il tient très bien et coûte peu.

3. L'intégration par API

La donnée quitte un système et entre dans l'autre sans intervention humaine, avec une trace de ce qui est passé et de ce qui a échoué.

Trois conditions décident de la faisabilité : l'API existe et couvre les objets voulus en lecture comme en écriture, l'éditeur accorde l'accès, et quelqu'un tient le lien dans la durée. Ce dernier point est celui qu'on sous-estime. Un lien est vivant : les versions évoluent, les jetons expirent, un champ change de nom de l'autre côté, et un lien qui casse en silence est pire qu'une ressaisie assumée. Prévoir une alerte en cas d'échec fait partie du chantier, au même titre que le développement.

Deux choix techniques se posent tôt. Le sens dominant d'abord : dans la plupart des cas, on écrit dans le logiciel métier et on lit des statuts en retour. Le mode de rafraîchissement ensuite : quand l'éditeur propose des notifications sur événement, elles coûtent moins cher aux deux parties qu'une interrogation répétée.

L'intégration se justifie quand le volume est régulier, quand la fraîcheur compte, ou quand plusieurs personnes dépendent de la même information. En dessous, son coût d'entretien dépasse le temps qu'elle libère.

Poser son diagnostic

La séquence tient en cinq étapes et se conduit sans prestataire.

1. Tracer le chemin d'une demande, du premier contact jusqu'à la facture, sur une feuille. Noter chaque endroit où une information change de support : message vers tableur, tableur vers logiciel, logiciel vers document, document vers comptabilité. Chacun de ces passages est un point de rupture.
2. Compter pendant deux semaines pleines. Pour chaque point de rupture : le nombre de passages, le temps moyen constaté, la personne qui l'effectue. Deux semaines suffisent à faire apparaître les creux et les pointes, une seule journée n'y suffit pas.
3. Vérifier l'existence de l'API. Trois questions à poser à chaque éditeur : existe-t-il une API documentée, quels objets couvre-t-elle en lecture et en écriture, à quelles conditions l'accès est-il ouvert (coût, contrat, instruction d'une demande, délai). Ajouter une quatrième question sur les notifications sur événement.
4. Décider où vit la vérité. Pour chaque donnée partagée, un système fait foi et les autres la reçoivent. Cette décision est organisationnelle, elle se prend avant la technique, et l'éviter produit les conflits de version qu'on attribue ensuite à l'outil.
5. Estimer le coût d'entretien, distinct du coût de mise en place. Un lien se surveille, se corrige et se met à jour.

Quand le chemin comporte plus de trois points de rupture, ou quand la question dépasse deux logiciels, le cadrage devient un travail en soi et il existe des dispositifs pour le financer : voir le cadrage Diag Data IA. Pour les cabinets soumis au secret professionnel, la question de l'endroit où vivent les données et de qui peut y accéder se traite avant celle du connecteur : voir professions réglementées.

Ce que change un lien qui fonctionne

La donnée entre une fois, à l'endroit où elle arrive. L'erreur de frappe reste possible, elle change de nature : elle se produit à la source, se voit à la source, et se corrige une seule fois au lieu de se propager en deux exemplaires divergents.

Le point de collecte devient unique, donc une demande sans réponse devient une anomalie visible plutôt qu'un événement supposé.

Le reporting consolidé devient possible, parce qu'un système au moins voit les deux périmètres. C'est souvent le gain le moins attendu et le plus durable.

Ce qui ne bouge pas mérite d'être dit : le logiciel métier reste le logiciel métier. Le planning, la facturation et le suivi terrain continuent d'y vivre. Le lien traite ce qui se passe avant, et ce qui doit se relire après.

Aucun de ces effets ne se traduit par un pourcentage annonçable d'avance, et les taux annoncés avant mesure ne reposent sur rien. Le seul chiffre qui compte est celui de l'étape 2, mesuré chez vous, avant puis après.

Pour faire relire votre chemin de données par quelqu'un qui l'a déjà fait sur des flux comparables, écrivez-nous.