Le 1er septembre 2026, dans quelques jours, plus de sept millions d'entreprises françaises devront être en mesure de recevoir une facture électronique par l'intermédiaire d'une plateforme agréée par l'État (economie.gouv.fr, réforme de la facturation électronique). Le PDF envoyé par courriel ne sera plus conforme. Pour beaucoup de dirigeants, c'est la première fois que l'administration leur impose de faire dialoguer leur logiciel de facturation avec un système extérieur. Autrement dit, une intégration. Le sujet vient de sortir du service informatique pour atterrir sur le bureau du gérant.
En bref. Connecter ses logiciels entre eux consiste à faire circuler automatiquement des données d'un outil à l'autre, par leurs API. Trois voies existent : le connecteur natif, la plateforme d'automatisation et le développement sur mesure. La difficulté n'est presque jamais technique. Elle tient à une seule question : quel outil détient la vérité.
Pourquoi vos logiciels ne se parlent pas
Le Baromètre France Num 2025, mené auprès de 11 021 entreprises, montre que 88 % des TPE et PME utilisent au moins une solution de gestion et que près de 70 % sont équipées d'un logiciel de facturation (France Num, Baromètre 2025). L'équipement n'est donc plus le problème. L'empilement l'est. Chaque outil a été choisi séparément, à un moment différent, pour régler un besoin précis, et chacun garde ses données dans son coin.
Cette architecture par accumulation produit toujours les mêmes symptômes. Un client saisi trois fois, sous trois orthographes. Une commande validée quelque part qui n'arrive jamais en comptabilité. Un tableau de bord dont plus personne ne croit les chiffres. Le coût réel n'est pas le temps de recopie, il est dans la défiance : dès que deux écrans affichent deux vérités, vos équipes cessent de faire confiance aux deux et retournent au tableur.
Les trois façons de connecter deux logiciels
Toutes les connexions ne demandent pas le même effort et n'offrent pas la même liberté. Voici comment je les départage quand un dirigeant m'expose sa situation.
| Méthode | Quand elle convient | Sa vraie limite |
|---|---|---|
| Connecteur natif de l'éditeur | Les deux outils sont répandus et le besoin est standard | Vous ne pouvez faire circuler que ce que l'éditeur a décidé d'exposer |
| Plateforme d'automatisation (Zapier, Make, n8n) | Flux simples, volumes modérés, besoin d'aller vite | Une dépendance de plus, et la facture suit le volume |
| Développement sur mesure via API | Logique métier propre à vous, volumes importants, flux critique | Demande du cadrage et un vrai suivi dans la durée |
| Reprise par un outil unique | Les logiciels en place ne tiennent plus la charge de toute façon | Chantier bien plus lourd qu'une simple connexion |
La bonne réponse est presque toujours un mélange. Du natif là où il suffit, une plateforme pour le gros du trafic, du sur mesure sur le flux dont dépend votre facturation. Ce qui compte n'est pas de choisir un camp, c'est de savoir pourquoi vous avez choisi celui-là pour ce flux précis. Si vous hésitez encore entre acheter un outil du marché et faire développer le vôtre, la question se pose en amont, et je l'ai traitée dans l'article sur le logiciel sur mesure face au logiciel du marché.
La vraie question n'est pas technique : qui détient la vérité ?
C'est ici que la plupart des projets d'intégration dérapent, et c'est le point que les guides sur le sujet passent sous silence. Avant d'écrire la moindre ligne de connexion, il faut désigner, pour chaque type de donnée, l'outil qui fait foi.
Prenons l'adresse d'un client. Elle existe dans votre CRM, dans votre logiciel de facturation, peut-être dans votre outil de livraison. Un commercial la corrige dans le CRM le mardi. La comptabilité la corrige autrement dans la facturation le jeudi. Sans règle, la synchronisation applique la dernière modification reçue, ce qui revient à laisser le hasard arbitrer vos données clients. Avec une règle nommée, le CRM fait foi pour les coordonnées, la facturation fait foi pour les montants, le conflit disparaît parce qu'il ne peut plus se produire.
Cette décision n'est pas informatique, elle est organisationnelle. Elle demande de trancher qui, dans l'entreprise, a le droit de modifier quoi. C'est la raison pour laquelle je refuse de commencer une intégration par un choix d'outil. Tant que la source de vérité n'est pas désignée pour chaque donnée, on ne construit pas un système : on construit une machine à fabriquer des doublons plus vite qu'à la main.
Faut-il synchroniser dans les deux sens ?
Rarement, et rarement au départ. Un flux à sens unique est infiniment plus simple à comprendre, à tester et à réparer. La synchronisation bidirectionnelle oblige à gérer les conflits de modification, l'ordre d'arrivée des mises à jour et les boucles, quand l'outil A prévient B, qui prévient A en retour. Commencez par un sens. Vérifiez qu'il tient trois mois en conditions réelles. N'ajoutez l'autre que si le métier le réclame vraiment.
Ce qui casse en production, et qu'aucune démonstration ne montre
Une intégration marche toujours le jour de la mise en service. Elle est testée, on regarde la donnée passer d'un écran à l'autre, tout le monde est content. Le sujet, c'est le sixième mois.
Le danger n'est pas la panne visible, celle qui affiche un message d'erreur. C'est l'échec silencieux. La connexion cesse de fonctionner un jeudi soir, personne n'est prévenu, et vous découvrez trois semaines plus tard que quatre-vingts commandes ne sont jamais arrivées en préparation. J'ai vu ce scénario se produire sur des outils bien plus chers que ce que paient nos clients. Une intégration sérieuse prévoit donc trois choses dès le premier jour : une alerte quand un échange échoue, un journal consultable de ce qui est passé, et la capacité de rejouer les opérations manquées sans créer de doublons.
Ce dernier point mérite qu'on s'y arrête. Rejouer un flux sans doublonner suppose que chaque opération porte un identifiant unique, pour que le système reconnaisse ce qu'il a déjà traité. C'est deux heures de travail au moment de la conception. Sans ça, la seule façon de rattraper un incident consiste à faire du tri à la main dans la base, et ça, c'est plusieurs jours.
Et si votre logiciel métier n'a pas d'API ?
C'est le cas le plus fréquent dans les PME, et curieusement le moins traité. Beaucoup de logiciels métier installés il y a dix ans par un éditeur régional n'exposent aucune interface. Plusieurs portes de sortie existent quand même.
La première est l'export de fichier planifié. Le logiciel sait presque toujours produire un fichier, et un fichier déposé chaque nuit au même endroit peut être récupéré, contrôlé et injecté automatiquement ailleurs. Ce n'est pas élégant, ça fonctionne, et pour un flux quotidien c'est souvent suffisant. La deuxième est l'accès en lecture à la base de données, quand l'hébergement le permet et que l'éditeur l'autorise par écrit. La troisième consiste simplement à demander : une API existe parfois, non documentée sur le site commercial, disponible en option.
Si aucune de ces portes n'existe et qu'aucune n'est prévue, prenez-le comme une information sur la suite. Un éditeur qui verrouille l'accès à vos propres données vous enferme, et cet enfermement finira par vous coûter plus cher que le remplacement de l'outil. C'est exactement le raisonnement qui pousse certaines entreprises vers le développement de leur propre logiciel métier, non par goût de la technique, mais pour cesser de dépendre du bon vouloir d'un tiers.
Le piège de la dépendance : quand l'éditeur ferme la porte
Une API n'est pas un acquis, c'est une décision commerciale que quelqu'un d'autre peut revoir. Le cas le plus documenté reste celui de Twitter, devenu X : en février 2023, la plateforme a supprimé l'accès gratuit à son API, avec une nouvelle grille tarifaire qui montait jusqu'à des paliers hors de portée pour la plupart des développeurs (Siècle Digital). Du jour au lendemain, des outils tiers qui fonctionnaient depuis des années se sont arrêtés.
Aucun éditeur de logiciel de gestion n'est à l'abri d'une décision comparable, et vos connexions ne survivront pas toutes à un rachat ou à un changement de stratégie. La parade n'est pas de refuser de connecter, ce serait absurde. Elle consiste à savoir, pour chaque flux, ce qui se passe le jour où il s'arrête. Si la réponse est « on revient à la saisie manuelle pendant deux jours », le risque est acceptable. Si la réponse est « on ne peut plus facturer », alors ce flux ne devrait pas reposer sur une API tierce gratuite dont vous n'êtes pas client.
La facturation électronique, votre intégration grandeur nature
La réforme qui démarre le 1er septembre 2026 est un excellent terrain d'observation, parce qu'elle impose à tout le monde le même exercice au même moment. Toutes les entreprises doivent pouvoir recevoir leurs factures électroniques via une plateforme agréée, les grandes entreprises et les entreprises de taille intermédiaire doivent aussi les émettre, et les PME et micro-entreprises auront cette obligation d'émission au 1er septembre 2027 (calendrier officiel, economie.gouv.fr).
Concrètement, votre logiciel de facturation doit désormais parler à une plateforme extérieure, et les données de vos clients doivent être suffisamment propres pour passer le contrôle, à commencer par le numéro Siren qui devient une mention obligatoire. Les entreprises dont les outils communiquaient déjà vivront cette échéance comme une formalité. Celles qui gèrent leurs clients dans un tableur découvriront en quelques semaines tout ce que leur organisation avait laissé s'accumuler. C'est le même constat que dans l'article sur le passage d'Excel à un logiciel métier : une obligation extérieure ne crée pas le désordre, elle le rend visible.
Ce que j'ai appris en éditant nos propres logiciels
Chez Pictogramaweb, nous éditons plusieurs logiciels qui vivent en production chez des clients : Simply Spa, Simply Resa, Geko et Postwa. Chacun communique avec des systèmes que nous ne contrôlons pas, et c'est cette partie qui demande le plus d'attention dans la durée, bien avant les fonctionnalités visibles.
Je vais être honnête sur un point que les agences racontent rarement. Les connexions sont ce qui nous rappelle le plus souvent à l'ordre après la livraison. Un prestataire modifie un format sans prévenir, une authentification expire, un fournisseur change une règle de validation. Rien de dramatique quand la supervision est en place, très douloureux quand elle ne l'est pas. C'est aussi pour cette raison qu'une intégration ne se traite jamais comme un projet qui se termine : elle relève de la maintenance d'une application métier, au même titre que le reste.
L'autre chose que j'ai apprise, c'est qu'une connexion ne répare pas une organisation. Automatiser un processus bancal donne un processus bancal plus rapide. Quand un flux est confus pour vos équipes, il faut le remettre à plat avant de le brancher, sinon la connexion ne fera que propager la confusion à un deuxième outil. Le sujet rejoint alors l'automatisation des tâches répétitives, qui commence toujours par une remise en ordre.
Mon verdict
Connecter ses logiciels entre eux est aujourd'hui moins une question de faisabilité que de discipline. La technique est mûre, les API sont partout, les plateformes d'automatisation ont rendu les premiers flux accessibles sans écrire de code. Ce qui sépare une intégration qui tient d'une intégration qui pourrit, c'est trois décisions prises avant le branchement : quel outil détient la vérité pour chaque donnée, comment vous serez prévenu quand un échange échoue, et ce que vous faites le jour où la porte se ferme.
Commencez par un seul flux, celui qui vous coûte le plus de saisie aujourd'hui. Faites-le dans un seul sens. Surveillez-le pendant un trimestre. Puis étendez. Cette lenteur apparente est ce qui vous évitera de reconstruire l'ensemble dans dix-huit mois. Si vous voulez qu'on regarde ensemble quels flux méritent d'être connectés en premier dans votre entreprise, écrivez-moi, et nous partirons de vos outils réels plutôt que d'un schéma théorique.
Questions fréquentes
Comment connecter deux logiciels entre eux ?
Trois voies existent. Le connecteur natif, déjà prévu par l'éditeur, se limite à ce qu'il a décidé d'exposer. La plateforme d'automatisation, de type Zapier, Make ou n8n, orchestre les échanges sans coder et convient à la majorité des flux simples. Le développement sur mesure via API devient utile quand la logique métier est complexe, quand les volumes sont importants ou quand vous voulez garder la main sur le flux. La plupart des entreprises combinent les trois selon les cas.
Que faire si mon logiciel métier n'a pas d'API ?
Plusieurs solutions restent possibles. Un export de fichier planifié, récupéré et traité automatiquement, couvre déjà beaucoup de besoins. Un accès en lecture à la base de données peut suffire quand l'hébergement le permet et que l'éditeur l'autorise. Il faut aussi interroger l'éditeur, car une API existe parfois en option, sans être documentée sur le site. Si aucune porte n'existe et qu'aucune n'est prévue, c'est un signal à prendre au sérieux sur la pérennité de l'outil.
Faut-il synchroniser les données dans les deux sens ?
Rarement, et rarement dès le départ. Un flux à sens unique est bien plus simple à comprendre, à tester et à réparer. La synchronisation bidirectionnelle oblige à gérer les conflits de modification, l'ordre des mises à jour et les boucles entre les deux outils. Mieux vaut commencer par un seul sens, vérifier qu'il tient en conditions réelles, et n'ajouter l'autre que si le besoin métier le justifie vraiment.
Que se passe-t-il si une intégration tombe en panne ?
Le risque principal n'est pas la panne visible, c'est l'échec silencieux. Une connexion qui cesse de fonctionner sans alerte laisse croire que tout va bien pendant des semaines. Une intégration sérieuse prévoit donc une alerte en cas d'erreur, un journal des échanges consultable, et la possibilité de rejouer les opérations manquées sans créer de doublons. Ces trois points comptent autant que le branchement initial.
Photo : Team Nocoloco sur Unsplash
