Service

Intégration de systèmes
au Québec

Un environnement où la commande, l'inventaire et la facturation cessent de s'ignorer. La donnée entre une fois et circule ensuite toute seule.

L'intégration de systèmes consiste à faire communiquer des logiciels qui s'ignorent, pour qu'une donnée saisie une fois circule partout où elle sert. Je relie vos outils par leurs interfaces de programmation, avec une file de traitement, des réessais et un journal, pour qu'une panne retarde un échange sans jamais le perdre.

Le problème que ça règle

Chaque outil de l'entreprise est bon dans son coin et sourd à ce qui se passe à côté. La boutique connaît les commandes, la comptabilité connaît les factures, l'outil de suivi des clients connaît les contacts, et aucun des trois ne sait ce que les deux autres ont enregistré ce matin. La liaison entre eux existe pourtant : c'est une personne, deux onglets ouverts et du copier-coller. Tant que le volume est faible, ça passe pour un détail d'organisation. Quand il monte, ça devient un poste à temps plein que personne n'a jamais budgété.

Les plateformes de connecteurs sans code règlent la version facile du problème. Elles savent recopier un champ d'un outil vers un autre quand tout se passe bien. Elles cassent sur les cas particuliers, et les cas particuliers sont le métier : une commande annulée après facturation, un remboursement partiel, un client qui existe en double avec deux orthographes, un fichier qui arrive avec une colonne en trop. Elles facturent en plus à la tâche exécutée, donc l'addition grossit exactement quand l'entreprise va bien.

Le vrai sujet d'une intégration n'est pas le tuyau, c'est ce qui se passe quand le tuyau fuit. Une interface tombe deux heures, un jeton expire un dimanche, un fournisseur change son format sans prévenir, le même événement arrive deux fois. Une intégration sérieuse est d'abord un plan pour ces moments-là : une file d'attente qui retient ce qui n'est pas encore passé, des réessais, une alerte adressée à quelqu'un, et le moyen de rejouer un échange raté sans rien ressaisir.

Ce que ce n'est pas

Un mandat mal orienté coûte plus cher à tout le monde qu'un mandat refusé au premier appel. Voici donc ce que je ne vends pas, et ce que je dis quand la demande ne colle pas avec ce que je sais faire.

  • Ce n'est pas un connecteur monté en une après-midi pour la démonstration. Un échange qui marche une fois sur un jeu de données propre ne prouve rien. Ce qui prend du temps, c'est le comportement les jours où l'autre système répond mal, et c'est précisément ce que je facture.
  • Ce n'est pas de la magie contre un logiciel fermé. Si votre outil n'expose ni interface de programmation, ni notification sortante, ni export automatisable, je vous le dis au lieu de promettre une solution. Lire les écrans d'un logiciel comme le ferait un humain casse au premier changement d'affichage, et je ne vends pas ça comme une intégration.
  • Ce n'est pas une migration de données déguisée. Sortir dix ans d'historique d'un vieux système, le nettoyer et le réconcilier est un mandat à part entière, avec son propre calendrier. Le mélanger à une intégration en cours donne un projet dont plus personne ne sait où il en est.
  • Ce n'est pas un contrat d'exploitation continue. Je pose la surveillance, les alertes et le moyen de rejouer ce qui a échoué, pour que votre équipe puisse agir sans moi. Je ne vends ni astreinte de nuit ni engagement de réponse en quelques minutes.
  • Ce n'est pas de l'intégration sans accès réels. Il me faut des comptes de test chez vos fournisseurs et quelqu'un chez vous qui connaît les règles de gestion. Quand ces deux conditions ne sont pas réunies, je le dis avant de commencer plutôt que de facturer de l'attente.
  • Ce n'est pas un abonnement à la tâche exécutée. Une fois écrite, l'intégration tourne sur votre infrastructure et ne coûte pas plus cher le mois où votre volume double.

Ce que vous recevez

Le livrable n'est ni une maquette ni un rapport. C'est un logiciel qui tourne, avec ce qu'il faut autour pour qu'il continue de tourner le jour où je ne suis plus au dossier.

  • Une intégration qui tourne sur votre infrastructure, sans abonnement facturé à la tâche
  • La carte écrite des flux : quelle donnée part d'où, arrive où, et lequel des systèmes fait autorité en cas de désaccord
  • Une file de traitement avec réessais, pour qu'un service indisponible retarde un échange au lieu de le perdre
  • Les notifications entrantes vérifiées et protégées contre le double traitement
  • Un journal consultable de ce qui est passé, avec le moyen de rejouer un échange raté
  • Une alerte quand un flux bloque, envoyée à quelqu'un qui peut agir
  • La documentation des jetons, des limites de débit et de la marche à suivre le jour où un fournisseur change son format

L'outillage reste le même d'un projet à l'autre. Une pile réduite se maintient et se transmet ; une pile choisie pour être à la mode se paie deux ans plus tard, quand plus personne ne veut y toucher.

  • Django
  • Celery
  • Redis
  • PostgreSQL
  • API REST
  • Webhooks

Comment ça se passe

Toujours dans cet ordre, et vous voyez sortir quelque chose de chaque étape. Personne ne disparaît trois mois pour revenir avec une surprise.

  1. Cartographier avant d'écrire une ligne

    On liste les outils en place, ce que chacun détient, et les échanges qui se font aujourd'hui à la main. Cette carte tient sur une page et règle la moitié des désaccords avant qu'ils arrivent, parce qu'elle oblige à nommer qui détient quoi. C'est aussi là qu'on découvre les échanges dont personne ne parlait, ceux qu'une seule personne fait le vendredi soir.

  2. Vérifier ce que les interfaces permettent vraiment

    La documentation d'un fournisseur et son comportement réel ne coïncident pas toujours. Je teste dans un bac à sable avant de promettre quoi que ce soit : ce qui est exposé, ce qui ne l'est pas, les limites de débit, la pagination, le délai avant qu'une donnée écrite soit relisible. Une contrainte découverte à cette étape coûte une discussion, la même découverte trois semaines plus tard coûte une réécriture.

  3. Décider qui fait autorité

    Quand deux systèmes détiennent l'adresse d'un même client et qu'elles diffèrent, il faut une règle écrite, champ par champ. Sans cette décision, l'intégration finit par écraser à tour de rôle les corrections faites de chaque côté, et personne ne comprend pourquoi une adresse redevient fausse toute seule.

  4. Écrire en tenant la panne pour normale

    Le code part du principe que l'autre système sera indisponible un jour. Chaque échange passe par une file, se réessaie, et laisse une trace consultable. Recevoir deux fois le même événement ne doit jamais produire deux factures : c'est une propriété qui s'écrit exprès, elle n'arrive pas toute seule.

  5. Faire tourner en parallèle avant de basculer

    L'intégration tourne à côté du processus manuel pendant une période, et on compare les résultats. C'est la seule façon honnête de découvrir les cas particuliers que personne n'avait mentionnés, et ça se fait sans risquer une facture fausse envoyée à un vrai client.

  6. Surveiller, puis passer la main

    Alertes en place, journal lisible par quelqu'un qui n'est pas développeur, documentation des jetons et de leur renouvellement. Vous devez pouvoir voir par vous-même qu'un flux est bloqué, et rejouer ce qui a échoué sans m'appeler.

Ce que ça change une fois en ligne

Le mot intégration recouvre deux travaux qu'on confond souvent. Le premier consiste à recopier des données d'un système vers un autre, en continu. Le second consiste à faire qu'un événement dans un système déclenche une action dans un autre : une commande payée crée la facture, réserve le stock et lance la préparation. Le second est plus utile et nettement plus difficile, parce qu'il faut décider ce qui doit se passer quand une des trois actions échoue et pas les deux autres.

Le problème le plus coûteux d'une intégration n'est presque jamais technique, il tient à l'identité. Le même client porte deux orthographes selon le système, avec deux courriels différents. Le même produit porte deux codes. Tant que personne n'a décidé quelle clé fait foi, l'intégration crée des doublons proprement, régulièrement et à grande vitesse. Cette décision appartient à l'entreprise et pas au développeur, et c'est la première que je demande.

Vient ensuite une propriété qui porte un nom savant et recouvre une idée simple : recevoir deux fois le même événement ne doit produire qu'un seul effet. Les fournisseurs renvoient volontairement leurs notifications quand ils n'ont pas reçu de confirmation, donc un même message arrive parfois en double. Si l'échange n'a pas été écrit pour ça, la seconde copie crée une seconde facture, et personne ne s'en aperçoit avant la fin du mois.

Techniquement, ces échanges ne se font pas pendant qu'un utilisateur attend devant son écran. Ils partent dans une file de traitement, Celery côté exécution et Redis côté file, et se réessaient tout seuls. LocaSur repose sur ce mécanisme, parce qu'une place de marché entre locataires et propriétaires enchaîne en permanence des traitements qui n'ont aucune raison de bloquer quelqu'un.

Quand l'échange doit être instantané plutôt que différé, le mécanisme change. Find It Now garde une connexion ouverte pour qu'un objet retrouvé prévienne son propriétaire à l'instant où son code est scanné, sans que personne rafraîchisse une page. Send Me Now encaisse de vrais paiements, et un paiement est le cas d'intégration le plus exigeant qui soit : une transaction ne se rejoue pas à la légère, donc chaque événement doit être traçable et traité une seule fois.

Ce que le projet demande de votre côté tient en deux points, et il vaut mieux les dire avant de commencer. Il faut des accès de test réels chez vos fournisseurs, ce qui prend parfois plus de temps que prévu quand il faut passer par un revendeur. Et il faut quelqu'un chez vous qui connaît les règles de gestion et qui peut trancher, parce que les questions que soulève une intégration sont des questions de métier bien plus que des questions de code.

Ce que j'ai construit

Des applications en ligne, que vous pouvez ouvrir et juger vous-même. J'ai écrit le code de chacune, du premier écran à la mise en production.

Le reste est sur la page des réalisations.

J'écris aussi sur la façon dont ces applications sont faites :

Questions fréquentes

Combien coûte une intégration entre deux logiciels ?
Le prix dépend beaucoup moins du nombre d'outils que de la qualité de leurs interfaces. Relier deux services modernes qui envoient des notifications propres est un petit mandat. Relier un logiciel de gestion qui n'offre qu'un export nocturne en demande bien plus, pour le même résultat apparent. Je chiffre après avoir lu les documentations et testé les accès.
Est-ce que ça marche avec mon logiciel comptable ou ma boutique en ligne ?
Dans la plupart des cas oui, parce que les outils du marché exposent presque tous une interface de programmation. La bonne question est ce qu'ils exposent : certains donnent accès à tout, d'autres seulement à la lecture, d'autres encore imposent des limites qui interdisent une synchronisation en continu. Je vérifie ça avant de m'engager, et je vous dis franchement quand la réponse est non.
Pourquoi pas un outil de connexion sans code ?
Parce que c'est souvent le bon choix, et je le dis quand c'est le cas. Un déclencheur simple entre deux services courants ne mérite pas du code sur mesure. Le sur-mesure commence quand il y a des règles de métier, des cas particuliers, du volume, ou quand la facture à la tâche dépasse ce que coûterait d'écrire l'échange une fois pour toutes.
Que se passe-t-il si un service tombe ?
Rien de visible pour vos équipes, et c'est tout l'objet du travail. L'échange reste dans la file, se réessaie selon un délai qui s'allonge, et repart tout seul quand le service revient. Si la panne dure, une alerte part vers quelqu'un qui peut agir, et le journal permet de rejouer ce qui manquait une fois le service rétabli.
Combien de temps prend une intégration ?
Un échange simple entre deux services bien documentés se livre en jours. Un environnement où quatre outils s'échangent des données dans les deux sens se compte en semaines. Ce qui allonge le plus les délais est presque toujours l'obtention des accès de test chez vos fournisseurs, pas l'écriture du code.
Et si le fournisseur change son interface ?
Ça arrive, et l'intégration est écrite pour que ça se voie tout de suite : un format inattendu déclenche une erreur explicite et une alerte, au lieu d'écrire silencieusement des données fausses pendant trois semaines. La correction reste du travail, mais elle se fait en connaissance de cause plutôt qu'après avoir découvert le dégât.
Est-ce que vous pouvez créer une interface pour notre logiciel maison ?
Oui, c'est le cas inverse et il est fréquent : l'outil interne détient les données utiles et rien ne peut aller les chercher. J'expose ce qu'il faut, avec authentification, droits par rôle et documentation, pour que vos autres logiciels puissent s'y brancher sans que quelqu'un ouvre la base de données à la main.

Voir aussi : Automatisation et agents IA, Application web sur mesure. Tous mes services.

Parlons de ce que vous voulez construire

Le premier appel sert à savoir si le sur-mesure est la bonne réponse à votre problème. Si ce n'en est pas une, je le dis, et vous aurez perdu une demi-heure plutôt qu'un budget.

tokamdarius@gmail.com