Services
Des API, imports, exports et échanges de données fiables entre les systèmes métier que l’entreprise utilise déjà.
Une intégration est plus qu’une requête et une réponse JSON. Elle relie une action métier à un autre système : une demande du site devient un dossier CRM, une commande atteint l’ERP, un prestataire confirme un paiement ou la comptabilité renvoie le statut d’une facture.
Avant de choisir un endpoint, il faut savoir ce qui doit se produire, quel système détient les données, qui peut agir et ce que l’équipe fera si un service externe ne répond plus. Une intégration n’a de valeur que si le processus reste compréhensible en fonctionnement normal, lors d’un timeout, d’une livraison répétée ou d’une panne partielle.
Un contrat API décrit les données requises, les opérations disponibles, l’authentification, les formats de réponse, les erreurs et le versionnage. L’application exprime l’opération métier ; une couche d’intégration dédiée la traduit pour le prestataire. Les détails du CRM, des paiements ou de la comptabilité ne se répandent alors pas dans les modules de commande, support ou reporting.
Cette frontière limite les changements. Un nouveau prestataire ou une version d’API modifiée concerne une zone où le contrat, le mapping et le traitement des erreurs peuvent être vérifiés.
Une synchronisation bidirectionnelle devient fragile lorsque deux systèmes se pensent propriétaires de la même valeur. Pour chaque donnée métier, définissez le système de référence : par exemple le CRM pour les coordonnées, la comptabilité pour les factures, le CMS pour le contenu publié et l’ERP ou l’entrepôt pour le stock.
Une mise à jour à sens unique peut être simple. Dans les deux sens, une règle de conflit est nécessaire. Si le CRM et l’ERP modifient séparément un numéro de téléphone, la connexion ne peut pas décider quelle valeur est correcte. La règle peut privilégier le système de référence, comparer les horodatages dans des conditions définies ou envoyer le conflit en revue. Elle doit être décidée avant la mise en production.
Avant un appel externe, l’application vérifie les conditions qu’elle connaît : identité client, état de commande, devise, droits et documents requis. Elle valide ensuite la réponse comme toute donnée externe. Un HTTP 200 peut indiquer qu’une demande a été acceptée ; il ne prouve pas toujours qu’une facture a été créée, qu’un paiement a été finalisé ou qu’une commande est terminée.
Un timeout crée un état d’incertitude particulièrement important. Le système distant peut avoir exécuté l’opération alors que la réponse a été perdue. Pour créer une demande CRM, un workflow sûr enregistre la tentative locale, utilise un identifiant stable de demande ou d’événement lorsque le prestataire le permet, vérifie l’état distant si possible et rend les cas non résolus visibles aux équipes.
L’idempotence signifie qu’une requête répétée ne produit pas d’effet métier supplémentaire intentionnel. Elle dépend de la conception de l’application et, si nécessaire, du support du prestataire ou d’un identifiant commun. Elle réduit le risque de doublons, sans constituer une garantie universelle.
Un appel API synchrone convient à une interaction courte où l’utilisateur attend une réponse immédiate et limitée, par exemple une vérification de stock. Les imports, transferts de documents, synchronisations en masse et prestataires lents passent généralement par des traitements en arrière-plan. L’application enregistre le travail, affiche son état et continue à fonctionner malgré les délais du service externe.
Un webhook informe l’application qu’un événement est survenu ailleurs, par exemple une confirmation de paiement. Vérifiez la signature ou un autre mécanisme d’authentification, la charge utile, les doublons et le traitement dans le workflow contrôlé. La réception d’un webhook ne prouve pas que toutes les étapes métier suivantes sont terminées.
Les relances doivent être limitées aux erreurs temporaires. Une erreur de validation durable demande de corriger les données, pas d’ajouter du trafic. Si un prestataire reste indisponible, un disjoncteur applicatif ou une pause temporaire peut protéger l’application et laisser l’équipe décider de la reprise. La récupération peut prendre la forme d’une relance, d’un rapprochement avec le système de référence, d’une action compensatoire ou d’un traitement manuel, selon ce qui s’est déjà produit.
Utilisez uniquement les droits et les données nécessaires. Conservez les secrets dans une configuration adaptée, limitez l’accès par rôle et par organisation, utilisez un transport sécurisé et n’écrivez pas de données personnelles ou financières dans les logs sans nécessité ni protection. L’authentification confirme l’identité de l’appelant ; l’autorisation détermine ce qu’il peut faire.
La supervision doit montrer plus que des erreurs techniques : imports en attente, paiements en échec, tâches retardées, conflits de synchronisation et enregistrements à revoir. Une piste d’audit reliant l’enregistrement local, l’identifiant externe, le statut de la requête et le résultat métier facilite le support et le rapprochement.
Un système legacy n’a pas besoin d’être entièrement réécrit pour intégrer de manière fiable. Dans Symfony ou PHP, un petit service d’intégration peut encapsuler le client externe, le mapping, la validation et la gestion d’erreur. Des tests de caractérisation protègent le comportement établi avant de modifier la connexion. Des imports incrémentaux et une bascule progressive réduisent le risque lorsque la qualité ou la responsabilité des données est incertaine.
Les services d’IA peuvent passer par la même frontière, mais de façon proportionnée au processus : transmettre un contexte limité et approuvé, valider des résultats structurés et garder les droits ainsi que les actions métier finales dans l’application.
GiSoft conçoit et améliore des intégrations API autour des processus qui comptent : CRM, ERP, paiements, comptabilité, imports et services partenaires. Nous clarifions responsabilités et contrats, construisons un fonctionnement sûr et rendons les incidents visibles. La bonne conception dépend des systèmes, des volumes, des données et des conséquences métier. L’objectif est un échange fiable, pas la promesse que les services externes ne tomberont jamais en panne.
