Prenez une entreprise de trente-cinq personnes, sans informaticien en interne. Un logiciel de gestion commerciale installé sur un serveur en 2014, un CRM en ligne choisi par le directeur commercial en 2021, un outil de planning arrivé avec le nouveau chef d’atelier, la paie chez l’expert-comptable, et un tableur de suivi que tout le monde ouvre le lundi matin. Cinq outils, cinq bases de données, et la même fiche client dans quatre d’entre elles, avec quatre orthographes différentes. Personne n’a décidé cela. C’est arrivé, un achat après l’autre, chacun pour une bonne raison.
PME sans DSI : comment relier vos logiciels et supprimer jusqu’à 16 heures de ressaisie par semaine
Le prestataire informatique s’occupe des postes, du réseau et des sauvegardes. Chaque éditeur s’occupe de son produit. L’espace entre les deux, celui où l’information devrait circuler, n’appartient à personne.
🔗 Ce que vous devez retenir de cette thématique :
Connecter ses logiciels et supprimer la ressaisie
Lire aussi cet article sur teletravail : repenser les approches pour fournir un soutien constant et adapté aux besoins des employés
CRM, gestion commerciale, planning : pourquoi vos logiciels ne communiquent pas et les 5 méthodes pour enfin les connecter
C’est là que se fait la triple saisie, et c’est de cet espace qu’il est question ici. Des ateliers comme IAscension se sont organisés pour construire ce type de pont au forfait, avec un pilote avant l’engagement, mais avant de parler de solution, il faut comprendre pourquoi la ressaisie s’installe et pourquoi elle dure.
Pourquoi la même information est saisie trois fois
Chaque logiciel a été acheté pour résoudre un problème local, et chacun a son propre modèle de données. Le CRM appelle « compte » ce que la gestion commerciale appelle « tiers » et ce que le planning appelle « client ». Aucun des trois ne connaît l’identifiant des deux autres.
La ressaisie est aussi, il faut le dire, un choix rationnel à court terme. Elle coûte quatre minutes, invisibles, réparties sur plusieurs personnes. Un projet d’intégration a un devis, une date et un risque, même si ce que coûte réellement un pont entre deux logiciels est aujourd’hui bien plus bas qu’il y a cinq ans. Entre un coût diffus et un coût visible, une entreprise sans DSI choisit le coût diffus, jusqu’au jour où quelqu’un fait le compte : quatre minutes, trois fois par dossier, quatre-vingts dossiers par semaine, c’est seize heures hebdomadaires. Une demi-personne.
Les cinq façons de relier deux logiciels, de la plus propre à la plus fragile
1. L’API documentée
Quand les deux outils exposent une interface de programmation, en général REST et JSON, avec une authentification par jeton, une pagination et des quotas, on est dans le cas favorable. Trois vérifications avant de se réjouir. L’API permet-elle d’écrire, et pas seulement de lire ? Beaucoup d’offres d’entrée de gamme exposent la lecture et réservent l’écriture aux forfaits supérieurs. Les champs personnalisés que l’entreprise a créés sont-ils accessibles ? Et existe-t-il un environnement de test, ou faut-il développer directement sur les données de production ?
2. Le webhook
L’outil vous appelle quand quelque chose se passe : nouvelle commande, devis signé, fiche modifiée. C’est la bonne approche pour du temps réel, à condition d’avoir un point d’entrée public en HTTPS, de vérifier la signature des appels, et surtout d’être idempotent, parce que le même événement arrivera deux fois un jour ou l’autre. Ce qui casse : votre point d’entrée est indisponible pendant deux heures, et l’émetteur ne rejoue pas les événements manqués. Un webhook sans réconciliation périodique par l’API est une intégration qui perd des données en silence.
3. Les connecteurs natifs et les plateformes d’intégration
Zapier, Make ou n8n permettent de relier deux outils en une heure, sans écrire de code, pour des flux simples. n8n a un avantage net pour une PME : il s’héberge sur son propre serveur, les identifiants restent chez soi, il n’y a pas de coût par opération, et les scénarios s’exportent en JSON, donc se versionnent dans un dépôt git comme n’importe quel code. Les nœuds de code absorbent les cas tordus.
Ce qui casse, en revanche, ne dépend pas de l’outil. Le scénario construit par un stagiaire et rattaché à son compte personnel. Le déclencheur qui interroge l’outil toutes les quinze minutes et rate des éléments quand la liste dépasse une page. La branche d’erreur jamais configurée, si bien que le flux échoue sur trois pour cent des cas sans que personne ne le sache. Le champ personnalisé renommé par un utilisateur, qui vide une colonne pendant trois semaines.
4. Les fichiers : exports, imports et ETL léger
Un export CSV déposé sur un SFTP ou un dossier partagé, un script qui transforme et charge dans l’autre outil. C’est la méthode la moins élégante et souvent la plus robuste, parce que tout le monde la comprend et qu’elle se rejoue. Les pièges sont toujours les mêmes : l’encodage (Latin-1 contre UTF-8, et les accents qui se transforment en points d’interrogation), le format des dates, le séparateur point-virgule ou virgule, les décimales à la française, l’ordre des colonnes qui change après une mise à jour de l’éditeur. Et le script qui tourne sur le poste de quelqu’un, éteint le vendredi soir. Règle simple : un serveur, un journal par exécution, un contrôle du nombre de lignes lues et écrites.
5. Quand rien n’existe : la boîte mail et l’écran
Le logiciel fermé envoie pourtant des courriels : « nouvelle commande n° 4521 », avec les informations dedans. Traiter ces notifications comme une file d’attente est étonnamment stable, à condition de ne rien supposer sur leur mise en forme. L’automatisation d’interface, qui pilote l’écran à la place d’un humain, reste le dernier recours : elle casse à chaque mise à jour visuelle. Ce que l’IA a changé sur ce terrain, c’est la lecture de texte non structuré. Extraire d’un mail ou d’un PDF le client, les dates, les quantités, avec un score de confiance, était impraticable il y a trois ans. C’est devenu la partie facile.
Ce qui casse vraiment, d’après ce que l’on répare
Le référentiel, d’abord. Avant toute ligne de code, il faut décider quel outil est maître de la fiche client, et quel identifiant stable la désigne : un code client, un SIREN, jamais un nom saisi librement. Sans cela, chaque synchronisation fabrique des doublons, et les doublons se propagent dans tous les outils reliés.
L’idempotence, ensuite. Chaque écriture doit porter l’identifiant de sa source, pour qu’un rejeu ne crée pas une seconde commande. Puis les exceptions silencieuses : un flux qui échoue sur un cas sur trente sans alerte est pire qu’une ressaisie, parce que la ressaisie, au moins, on la voit. Il faut un journal, une file des cas non traités, et une alerte quand elle grossit. Enfin, le changement côté éditeur : une version d’API dépréciée, un champ renommé. Une vérification mensuelle prend dix minutes et évite une découverte à chaud.
Et le point le plus fréquent dans les petites structures : le savoir dans une seule tête. L’intégration qui n’est ni documentée ni versionnée disparaît avec la personne qui l’a faite.
La validation humaine comme garde-fou
Ce n’est pas une position morale, c’est une architecture. Le pont prépare : il crée une fiche marquée « à valider », dépose un brouillon, place une carte dans une colonne « à vérifier ». Une personne valide, dans son outil habituel, en quelques secondes. Trois bénéfices. Les erreurs de lecture sont arrêtées avant de se propager. L’équipe adopte l’outil, parce qu’elle garde la main. Et la responsabilité de ce qui part vers un client reste humaine.
La validation se place sur l’écriture qui engage, l’envoi au client ou la création d’une facture, pas à chaque étape intermédiaire. Et elle peut se relâcher avec le temps, sur mesure : quand un flux tourne depuis trois mois avec un taux d’erreur mesuré sous un pour cent sur deux cents cas, on peut décider de valider par exception plutôt que systématiquement. On le décide sur des chiffres, pas sur une impression.
Par où commencer quand on n’a pas de DSI
Une demi-journée d’inventaire des flux, avec les personnes qui font les saisies et non avec la direction : quelle information naît où, et où elle est recopiée. Le choix du référentiel maître. Puis le flux le plus coûteux, traité seul, sur un cas, jusqu’au bout, avant de généraliser. Le forfait avec pilote, évoqué au début, répond à l’objection du coût visible : on sait ce que l’on paie, et on voit le résultat sur un cas réel avant de généraliser.
Quelle que soit la méthode retenue, quatre exigences ne se négocient pas : le code ou les scénarios tournent sur un serveur et non sur un poste, ils sont versionnés, ils sont documentés, et une seconde personne sait les faire redémarrer. Une PME sans DSI peut très bien avoir un système d’information qui se parle. Elle ne peut pas se permettre qu’il dépende d’une seule personne.
Complétez votre lecture avec cet article sur le budget réel du déploiement IoT en entreprise : intégration, connectivité récurrente, plateforme logicielle, maintenance et cybersécurité
- Interopérabilité en PME sans DSI : pourquoi tout est saisi trois fois - 14 septembre 2026
- Entreprise en région parisienne : où s’implanter pour profiter au mieux de l’attractivité de Paris ? - 13 septembre 2026
- Comment le e-commerce B2B transforme le secteur de la distribution alimentaire en gros - 8 septembre 2026
