API & intégrations

Le problème : des outils qui ne se parlent pas

La plupart des entreprises que je croise n’ont pas un outil, elles en ont cinq : un ERP pour la gestion, un CRM pour les clients, une boutique en ligne, un outil de facturation, un logiciel métier propre au secteur. Chacun fait bien son travail, mais aucun ne parle aux autres. Résultat : quelqu’un, dans l’équipe, passe une partie de sa semaine à recopier des commandes d’un système vers un autre, à ressaisir des coordonnées client, à exporter un fichier CSV pour l’importer ailleurs. C’est long, ça introduit des erreurs de saisie, et ça devient intenable dès que le volume augmente.

Une intégration API, c’est brancher ces outils entre eux pour que la donnée circule toute seule : une commande passée sur le site crée automatiquement la fiche client dans le CRM, un paiement validé déclenche la facture, un changement de stock côté logistique se répercute sur la boutique. Ce n’est pas un projet magique qui règle tout d’un coup, c’est un travail de plomberie technique, précis, qui demande de comprendre le fonctionnement réel de chaque système avant d’écrire une ligne de code. Deux outils censés faire la même chose ne stockent presque jamais leurs données de la même façon, et une bonne partie du travail consiste justement à réconcilier ces différences sans rien perdre au passage.

Ce que je connecte concrètement

Je travaille aussi bien sur des connexions ponctuelles entre deux outils que sur la construction d’une couche d’API complète quand aucune des briques existantes n’en propose une utilisable. Les besoins reviennent souvent autour des mêmes familles :

Comment je conçois une intégration

Je commence toujours par lire la documentation des API existantes en détail, avant de m’engager sur un délai. Une API mal documentée ou avec des limites de fréquence basses change complètement la façon dont on doit travailler, et je préfère le découvrir avant le devis plutôt qu’en cours de développement. Quand c’est possible, je privilégie les webhooks — l’outil me prévient quand quelque chose change — plutôt que le polling, qui consiste à interroger l’API toutes les X minutes pour vérifier si quelque chose a bougé. C’est plus réactif et ça évite de saturer des API qui limitent le nombre d’appels.

Quand aucun des systèmes en place n’expose d’API exploitable, je construis une couche intermédiaire, généralement en NestJS : c’est ce que j’utilise pour bâtir des API robustes, avec une architecture claire, une validation stricte des données en entrée et des logs qui permettent de comprendre ce qui s’est passé en cas d’échec. Si le projet s’appuie déjà sur une base Symfony existante, je reste dans cet écosystème plutôt que d’ajouter une techno supplémentaire à maintenir. Avant toute mise en production, je teste les cas d’échec autant que les cas de succès : que se passe-t-il si l’API distante répond avec du retard, renvoie une erreur, ou coupe en plein milieu d’une synchronisation. C’est souvent là que se jouent les vraies pannes, pas sur le chemin nominal.

Les cas où je vous le déconseille

Une intégration API n’est pas toujours la bonne réponse, et je le dis quand c’est le cas plutôt que de facturer un projet qui ne résoudra rien.

• Vos données ne sont pas fiables. Si votre CRM contient des doublons, des fiches incomplètes ou des statuts jamais mis à jour, une synchronisation automatique va simplement propager le désordre plus vite, sur plusieurs outils au lieu d’un seul. Il faut d’abord nettoyer, pas connecter.
• L’outil en face n’a pas d’API publique. Certains logiciels, souvent des solutions métier fermées, ne proposent aucune API documentée. La seule alternative est parfois le scraping ou l’automatisation d’interface, une solution fragile qui casse au moindre changement visuel de l’outil. Je préfère le dire clairement plutôt que de vendre une intégration qui tiendra six mois.
• Le besoin est ponctuel. Un export une fois par mois ne justifie pas une intégration temps réel maintenue en continu. Un script d’export planifié suffit largement, coûte moins cher et demande moins de suivi.

Sécurité, robustesse et maintenance

Une intégration qui fonctionne le jour de la mise en ligne et qui casse trois semaines plus tard sans que personne ne le remarque n’a aucune valeur. Je mets en place une gestion d’erreurs explicite — un webhook qui échoue doit être rejoué, pas silencieusement perdu — et des logs suffisamment clairs pour diagnostiquer un problème sans avoir à relire tout le code. Les clés d’API et identifiants sensibles sont stockés en variables d’environnement, jamais en clair dans le dépôt de code, et les accès sont limités au strict nécessaire, chaque intégration n’ayant accès qu’aux données dont elle a réellement besoin.

Les API tierces changent aussi de leur côté : une version dépréciée, un format de réponse modifié, une limite de fréquence resserrée. C’est la cause la plus fréquente de panne sur ce type de projet, et c’est aussi pour ça qu’une intégration livrée sans aucun suivi finit presque toujours par se dégrader silencieusement, jusqu’au jour où quelqu’un remarque qu’une commande sur deux n’est plus arrivée dans le CRM depuis des semaines.

Combien coûte une intégration

Le prix dépend surtout de la qualité de la documentation en face et du nombre de flux à synchroniser. Une connexion simple entre deux outils qui exposent déjà des API propres se chiffre en jours ; construire une couche d’API complète pour remplacer l’absence d’API côté outils existants est un projet plus long, proche d’une application sur mesure.

Pour un projet plus large — une API construite de zéro qui devient la colonne vertébrale de plusieurs outils — je fonctionne au forfait, sur la base d’une application sur mesure dès 5 000 € HT, cadrée en amont sur un périmètre précis plutôt que facturée à l’aveugle.