Réponse courte. On ne remplace pas la comptabilité, la facturation, l'ERP ou la caisse qui existent déjà ; on les relie, et le travail n'est pas dans le câble mais dans la couche d'intégration : une file où chaque message porte une clé d'idempotence, une table de correspondance où l'identifiant de l'application est stocké en face du numéro du logiciel cible, une transformation vers un contrat de données commun, un journal, et un rapprochement chaque soir qui liste les écarts au lieu de les cacher. Les connecteurs parlent la langue de chaque logiciel : l'API quand elle existe, les exports et imports de fichiers quand le logiciel tourne sous Windows depuis dix ans, la base de données en lecture seule, l'écran en dernier recours. Seize semaines, dont deux d'inventaire et deux où le premier flux tourne en parallèle de la saisie.
Ce guide s'adresse au distributeur dont les commandes sont ressaisies dans la facturation, à la chaîne de boutiques dont les caisses envoient un fichier le soir que quelqu'un retape, à la clinique dont l'agenda et la facturation ne se parlent pas, à l'agence immobilière dont les quittances finissent chez le comptable en photo, et au fondateur installé en France qui lit « intégration ERP » dans un devis sans savoir ce que cela cache. Il ne compare pas des logiciels, et le guide sur la migration des vieux logiciels de gestion traite du cas où l'on finit par remplacer ; ici, on garde et on relie.
Ce que les chiffres disent
L'intégration est devenue le métier normal du logiciel. Le rapport State of the API 2025 de Postman, septième édition, interroge plus de 5 700 développeurs et professionnels entre juillet et août 2025 ; selon son communiqué du 8 octobre 2025, 65 % des organisations tirent des revenus de leurs API et près d'un développeur sur quatre conçoit déjà ses API pour des agents d'IA ; l'édition 2024 disait que près des trois quarts des professionnels travaillaient « API d'abord ». Ce sont des chiffres mondiaux, relayés par la presse spécialisée, à lire comme une direction : le logiciel qui n'expose rien devient l'exception, et c'est pourtant celui qu'on trouve dans la plupart des entreprises algériennes, sous Windows, installé en 2016.
Les éditeurs modernes documentent leur porte d'entrée, et ses conditions. Odoo, présent chez beaucoup de PME, expose son API externe en XML-RPC, avec un appel d'authentification qui renvoie un identifiant d'utilisateur, des clés d'API depuis la version 14 qui remplacent le mot de passe dans les scripts, et, selon la documentation de la version 18, un accès aux données par l'API externe réservé aux plans « Custom » sur Odoo Online ; une entreprise qui compte intégrer son Odoo hébergé par l'éditeur doit le vérifier avant de signer un devis. Côté retours, l'initiative Standard Webhooks, portée par un comité où siègent des ingénieurs de Zapier, Twilio, Svix et Kong, rappelle que « toute implémentation de webhooks doit protéger ses utilisateurs contre le SSRF, l'usurpation et le rejeu », et fournit des outils pour signer et vérifier ; des fournisseurs d'IA comme OpenAI, Anthropic et Google l'ont adoptée. Ce que cela impose à l'entreprise : un webhook reçu sans vérification de signature est une porte ouverte, et un webhook reçu deux fois doit produire un seul effet.
Le reste est algérien et ne se trouve dans aucun rapport : le logiciel de facturation sous Windows dont l'éditeur ne répond plus, le comptable externe qui veut un fichier et pas une API, la caisse qui exporte un CSV à la fermeture, le classeur Excel que trois personnes modifient. Nous n'avons pas de statistique sur ces cas ; nous les rencontrons dans la quasi-totalité des projets, et ce guide est écrit pour eux autant que pour Odoo.
La vie d'une commande à travers les logiciels, en six moments
L'intégration ne se décrit pas par ses connecteurs mais par ce qui arrive à une commande confirmée dans l'application, jusqu'à ce que le comptable et le gérant voient le même chiffre.
L'événement naît dans l'application : une commande confirmée, horodatée, avec un identifiant créé une fois pour toutes, un identifiant aléatoire long, pas un numéro que la facturation attribuera plus tard. Le contrat de données est l'objet que tous les logiciels recevront : client, lignes, quantités, prix, taxes, références, dans un format unique écrit la première semaine ; chaque connecteur le traduit dans la langue de son logiciel, et la table de correspondance garde, pour chaque client, produit et commande, l'identifiant de l'application et celui de chaque logiciel. L'envoi passe par une file persistante : le message porte une clé d'idempotence, un statut et un nombre d'essais, et part par l'API si elle existe, par un fichier déposé dans un dossier surveillé sinon ; jamais deux fois, même si la connexion coupe après l'envoi, par le même mécanisme que le guide sur l'application hors ligne décrit pour le téléphone.
L'accusé et l'identifiant retour sont le moment qui fait tenir l'intégration dans le temps : la facturation renvoie son numéro, 2027-0142, et il est stocké en face de l'identifiant de la commande ; quand la réponse n'arrive pas, le statut « en attente » est visible, et un fichier importé se vérifie en relisant le résultat dans le logiciel. Sans cet identifiant en face, personne ne peut dire six mois plus tard quelle facture correspond à quelle commande, et c'est exactement ce qui se passe quand l'intégration a été faite « par un câble ». Le retour des événements fait le chemin inverse : le paiement saisi en comptabilité ou le stock corrigé dans l'ERP reviennent vers l'application, par webhook signé si l'éditeur en offre, par lecture périodique sinon, et l'application met à jour l'encours du détaillant ou la disponibilité du produit. Le rapprochement du soir compare les deux côtés, commande par commande : ce qui manque d'un côté, ce qui diffère en montant, ce qui est en double ; chaque écart est listé avec sa cause probable, rejoué d'un clic quand c'est un échec technique, arbitré par le comptable quand c'est un vrai désaccord. C'est le même rapprochement que le guide sur la caisse décrit entre le terminal de paiement et le relevé.
L'intégration, en cinq couches
Derrière les six moments, cinq couches, et celle du milieu est la seule qu'on construit vraiment.
L'existant reste en place : la comptabilité continue d'être tenue par le comptable dans son logiciel, la facturation continue de numéroter, l'ERP continue de gérer le stock, la caisse continue d'encaisser ; chacun garde ce qu'il sait faire, et c'est ce qui rend le projet acceptable pour les gens qui s'en servent. Les connecteurs parlent la langue de chaque logiciel, et rien d'autre ne la connaît : un connecteur XML-RPC pour Odoo, un connecteur de fichiers pour la facturation sous Windows, un lecteur de base pour l'ERP, un connecteur de webhooks pour l'éditeur SaaS ; quand un logiciel change, un connecteur change, et le reste ne bouge pas.
La couche d'intégration est le vrai livrable : la file persistante avec clés d'idempotence, la transformation vers le contrat de données, la table de correspondance des identifiants, le journal de chaque message et de chaque réponse, et les règles de ce qui fait foi, la comptabilité pour l'écriture, l'application pour la commande, l'ERP pour le stock. L'application émet et reçoit des événements et ne sait pas comment la comptabilité est tenue ; c'est ce qui permet de changer de comptable, de logiciel ou de prestataire sans toucher à l'application. La supervision est un écran que le comptable et le gérant lisent le soir : écarts par flux, rejets avec leur raison, files bloquées depuis plus d'une heure, et un bouton « rejouer » ; une intégration sans cet écran est une intégration dont on découvre les trous le 30 du mois. Le portail de commande et l'agent WhatsApp, décrits dans le guide sur le portail B2B et celui sur l'agent WhatsApp, sont des émetteurs d'événements comme les autres : la couche d'intégration ne sait pas si la commande vient d'un prévendeur, d'un portail ou d'un vocal.
«Brancher l'application sur l'API de la comptabilité, c'est poser un câble ; l'intégration, c'est la file, la clé, la correspondance et le rapprochement.»
Un exemple chiffré
Un exemple sur des hypothèses de volume, avec des résultats qui n'en sont pas : un distributeur, quatre logiciels, un mois.
Quatre logiciels : la facturation sous Windows installée en 2016 qui exporte et importe des fichiers, la comptabilité tenue par un cabinet externe qui veut un fichier d'écritures par mois, la caisse du dépôt qui exporte ses ventes à la fermeture, et la banque qui fournit un relevé à télécharger ; aucun des quatre n'a d'API, et l'intégration marche quand même, par fichiers et par lecture. 1 200 factures par mois sont créées dans la facturation à partir des commandes de l'application : un fichier déposé toutes les heures dans le dossier que le logiciel surveille, relu après import pour récupérer le numéro de facture et le stocker en face de la commande ; une commande dont le numéro n'est pas revenu en trente minutes apparaît en « en attente » sur l'écran de supervision.
Zéro ressaisie est le résultat qui ne dépend d'aucune hypothèse : la facture est tapée une fois, par personne, et les écritures partent chaque soir vers le comptable dans le format de son logiciel ; les paiements qu'il saisit reviennent le matin par lecture du fichier qu'il exporte, et l'encours du détaillant se met à jour dans l'application du prévendeur, décrite dans le guide sur la prévente. Trois heures à quinze minutes de rapprochement en fin de mois est notre hypothèse : les écarts sont listés chaque soir, une dizaine par jour au début, deux ou trois après un mois, et le 30 il ne reste rien à chercher. Les hypothèses à vérifier chez vous : combien de logiciels, combien de factures, qui ressaisit quoi aujourd'hui et combien de temps le rapprochement prend ; une journée d'observation au dépôt et une heure avec le comptable répondent aux quatre.
Six situations d'accès au logiciel existant
Tout logiciel se relie, mais pas de la même manière, et la première semaine du projet sert à savoir dans laquelle des six situations on est pour chacun.
L'API documentée est le cas confortable : Odoo en XML-RPC, un logiciel récent en REST, un éditeur SaaS avec des clés et des quotas. Le connecteur respecte la pagination et les limites, utilise une clé au nom de l'entreprise, et se teste dans un bac à sable avant de toucher la production ; il vérifie aussi que l'accès à l'API est inclus dans l'abonnement, ce qui n'est pas toujours le cas, comme la documentation d'Odoo le rappelle pour son offre en ligne. Les exports et imports de fichiers sont le cas algérien le plus fréquent : la plupart des logiciels de facturation et de comptabilité sous Windows savent importer et exporter du CSV ou de l'Excel ; l'application génère le fichier dans le format exact attendu, le dépose dans un dossier surveillé, et relit le résultat pour obtenir l'accusé. C'est moins élégant qu'une API et tout aussi fiable quand la relecture existe. La base de données accessible se lit, en lecture seule, pour récupérer factures et paiements ; on n'écrit jamais directement dans la base d'un logiciel qu'on ne maîtrise pas, on passe par son import officiel.
L'écran seul est le dernier recours : aucune API, aucun export utile, un éditeur injoignable ; l'automatisation de l'écran, un robot qui tape dans le logiciel comme un humain sur un poste dédié avec capture de preuve, marche, et elle casse à chaque mise à jour du logiciel ; elle s'accompagne toujours d'une date de sortie, souvent celle de la migration décrite dans le guide sur les vieux logiciels de gestion. L'éditeur SaaS étranger offre des webhooks qu'il faut vérifier par signature, protéger du rejeu et recevoir sur un serveur qui répond vite ; les clés sont au nom de l'entreprise, et le paiement du service en devise suit le guide sur le paiement du cloud depuis l'Algérie. Le fichier Excel partagé n'est pas un logiciel mais une habitude : soit l'application devient la source et Excel un export que chacun peut encore ouvrir, soit le classeur est importé une fois et arrêté ; le garder vivant à côté de l'application crée une troisième vérité.
«La comptabilité reçoit ; elle ne pilote pas l'opération.»
Six entreprises, ce qu'on relie d'abord
Six entreprises que nous équipons souvent, et pour chacune le premier flux relié, qui est toujours celui qui est ressaisi aujourd'hui.
Le distributeur relie d'abord les commandes de l'application à la facturation et les encaissements à la comptabilité ; le stock de l'ERP vers l'application et les relevés bancaires vers le rapprochement viennent ensuite. La chaîne de boutiques relie les ventes de chaque caisse au stock central et à la comptabilité chaque soir, puis la fidélité et les reçus vers l'espace client et les prix centraux vers les caisses. La clinique ou le cabinet relie les actes de l'agenda à la facturation et les paiements à la comptabilité, puis les résultats du laboratoire au dossier ; le cabinet dentaire qui reçoit la diaspora, décrit dans le guide dédié, a exactement ce premier flux.
L'agence immobilière relie les quittances de l'application à la comptabilité et les loyers encaissés au relevé du propriétaire décrit dans le guide sur l'appartement géré depuis la France, puis le relevé bancaire au rapprochement des loyers. Le SaaS d'un fondateur relie ses abonnements et ses factures à sa propre comptabilité par un export mensuel, puis fournit à chaque client un export dans le format du logiciel de ce client, ce qui est souvent la fonction qui fait signer une PME. L'importateur avec un ERP relie le catalogue, les prix et les encours de l'ERP au portail B2B et les commandes du portail à l'ERP, puis les statuts de livraison à l'agent WhatsApp. Dans les six cas, le premier flux va de l'événement vers la comptabilité, jamais l'inverse : la comptabilité reçoit, elle ne pilote pas l'opération, et c'est une règle qui évite la plupart des conflits de vérité.
Vu ailleurs : Odoo, Standard Webhooks, Postman, et ce qui se transpose
Trois textes publics disent l'essentiel. La documentation de l'API externe d'Odoo montre à quoi ressemble une porte d'entrée bien faite : un appel d'authentification, des clés d'API par utilisateur depuis la version 14, des méthodes pour chercher, lire, créer et écrire sur les modèles, et une condition commerciale, l'accès réservé à certains plans sur l'offre en ligne, qu'il faut lire avant de promettre une intégration. Ce qui se transpose à tout logiciel : vérifier l'accès avant de chiffrer, une clé par entreprise et jamais le mot de passe du gérant dans un script, et un bac à sable pour tester. Standard Webhooks dit l'autre moitié : un webhook est une requête qu'un tiers envoie à votre serveur, et il doit être signé, vérifié, horodaté et protégé du rejeu ; des fournisseurs d'IA l'ont adopté, et le même principe vaut pour le webhook de WhatsApp ou d'un éditeur de facturation en ligne.
Le rapport de Postman dit, lui, où va le marché : des API partout, des revenus qui en dépendent, et une part croissante d'API conçues pour être appelées par des agents d'IA plutôt que par des écrans ; l'agent WhatsApp décrit dans le guide dédié est exactement cela, un appelant d'API. Ce qui ne se transpose pas : l'hypothèse que l'API existe. En Algérie, elle n'existe pas pour la moitié des logiciels rencontrés, et la couche d'intégration est précisément ce qui rend les fichiers, les bases en lecture et même l'écran aussi fiables qu'une API : la file, la clé, la correspondance et le rapprochement ne dépendent pas du connecteur.
Les règles d'une intégration qui tient
Six règles, écrites la première semaine et relues à chaque nouveau flux. Une seule vérité par donnée : la commande appartient à l'application, l'écriture à la comptabilité, le stock à l'ERP, et chaque logiciel reçoit les autres données en copie ; deux logiciels qui prétendent tenir la même donnée divergent en un mois. Une clé d'idempotence par message et une file persistante, pour qu'un envoi répété ne crée qu'une facture. Une table de correspondance où chaque identifiant a son jumeau dans chaque logiciel, sans laquelle rien ne se rapproche. Un journal de chaque message et de chaque réponse, relisible par le comptable. Les comptes, les clés et les accès au nom de l'entreprise, jamais du prestataire, comme le guide sur l'application bloquée chez un développeur disparu le rappelle. Un bac à sable et une période en parallèle : le premier flux tourne deux semaines à côté de la saisie, les deux sont comparés chaque soir, et la saisie ne s'arrête que quand les écarts sont expliqués.
Une septième règle porte sur le cahier des charges : « intégration avec la comptabilité » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « les commandes confirmées créent une facture dans le logiciel X par import de fichier dans les trente minutes, le numéro de facture est stocké en face de la commande, et les écarts du jour sont listés à 20 h », et elle se vérifie à la recette, comme le recommande le guide sur le cahier des charges. Un devis qui chiffre « l'intégration » sans dire par quel moyen ni pour quels flux a chiffré autre chose.
Le calendrier 2027
Le calendrier est celui d'une intégration en seize semaines, dont les deux premières ne produisent pas de code et dont deux autres font tourner le premier flux en parallèle de la saisie.
Les semaines 0 à 2 font l'inventaire : chaque logiciel, sa version, son mode d'accès parmi les six, chaque flux ressaisi aujourd'hui et par qui, et le contrat de données écrit avec le comptable. Les semaines 2 à 4 obtiennent les accès : clés d'API au nom de l'entreprise, formats d'export et d'import testés sur de vraies données, bac à sable quand l'éditeur en offre, et l'éditeur contacté quand il faut lui demander quelque chose, ce qui prend toujours plus de temps que prévu. Les semaines 4 à 8 construisent la couche d'intégration : file, idempotence, correspondance, journal, écran des écarts, et le premier connecteur. Les semaines 8 à 10 font tourner le premier flux en parallèle : la facturation reçoit les factures de l'application et celles de la saisie habituelle, et les deux sont comparées chaque soir jusqu'à ce que les écarts soient compris. Les semaines 10 à 12 branchent les retours, paiements et stocks, et le rapprochement automatique. Les semaines 12 à 14 arrêtent la saisie flux par flux. Les semaines 14 à 16 installent la supervision dans la routine du comptable et font le bilan : écarts par flux et par semaine, rejets, et la décision sur le logiciel qu'on finira un jour par remplacer. Ce que coûte ensuite une année de cette couche, mises à jour des connecteurs comprises, suit la logique du guide sur la vie d'une application.
Ce qui fait échouer une intégration
Les intégrations que nous voyons échouer échouent presque toujours pour l'une de ces raisons.
- Brancher l'application directement sur l'API. Un câble, pas une intégration : au premier changement de logiciel ou de comptable, tout est à refaire.
- Pas de table de correspondance. Six mois plus tard, personne ne sait quelle facture est quelle commande, et le rapprochement devient impossible.
- Deux logiciels qui tiennent la même donnée. Le stock dans l'ERP et dans l'application, modifié des deux côtés ; ils divergent en un mois.
- Écrire directement dans la base d'un logiciel. Ça marche jusqu'à la mise à jour qui change une table ; l'import officiel, lui, survit.
- Pas de rapprochement quotidien. L'écart se découvre le 30, il fait trois semaines d'âge, et plus personne ne sait d'où il vient.
- Arrêter la saisie le premier jour. Sans les deux semaines en parallèle, les erreurs de format s'apprennent dans la comptabilité du mois.
- Les clés au nom du prestataire. Changer de prestataire revient à redemander tous les accès, et l'éditeur ne répond pas toujours.
Questions fréquentes
Les questions que nous recevons de gérants, de comptables et de fondateurs installés en France.
- Mon logiciel de facturation n'a pas d'API. Peut-on quand même l'intégrer ?
- Oui, dans presque tous les cas : la plupart des logiciels sous Windows importent et exportent des fichiers, et un fichier déposé dans un dossier surveillé puis relu pour en vérifier le résultat vaut une API quand la file, la clé et la correspondance existent derrière. La base de données se lit en lecture seule, et l'écran s'automatise en dernier recours, avec une date de sortie.
- Faut-il remplacer la comptabilité ou la garder ?
- La garder, presque toujours : la comptabilité est tenue par un comptable qui connaît son logiciel, et le projet consiste à lui envoyer des écritures justes dans son format plutôt qu'à lui imposer un outil. Le remplacement, s'il a lieu un jour, est un autre projet, décrit dans le guide sur la migration des vieux logiciels de gestion.
- Comment éviter les doublons de factures ?
- Par une clé d'idempotence sur chaque message de la file et par l'identifiant retour stocké en face de la commande : un envoi répété est reconnu et ne crée pas de seconde facture, et une facture déjà numérotée ne repart pas. Le rapprochement du soir attrape ce qui aurait échappé.
- Que se passe-t-il si l'éditeur du logiciel ne répond pas ?
- On n'attend pas : on relie par fichiers ou par lecture de base, qui ne demandent rien à l'éditeur, et on note la question pour la migration future. L'automatisation d'écran reste possible, sur un poste dédié, avec une date de sortie écrite.
- Qui regarde les écarts chaque soir ?
- Le comptable ou la personne qui ressaisissait avant : l'écran de supervision liste les écarts par flux avec leur cause probable et un bouton pour rejouer les échecs techniques ; les vrais désaccords, une remise non prévue, un prix différent, sont arbitrés par lui. Dix écarts par jour au début, deux ou trois après un mois.
- Combien de temps avant que la ressaisie s'arrête ?
- Dix semaines pour le premier flux, dont deux d'inventaire, deux d'accès, quatre de construction et deux en parallèle de la saisie ; puis un flux toutes les deux semaines environ. Un projet à quatre logiciels tient en seize semaines quand les accès arrivent à temps, et l'éditeur qui ne répond pas est ce qui allonge le plus souvent le calendrier.