Votre site reçoit une demande de devis. Quelqu'un l'ouvre, la recopie dans le CRM, crée la fiche client, puis va vérifier dans l'ERP si le produit est encore en stock. Pendant ce temps, la page produit affiche une disponibilité datée de la semaine dernière.
Cette recopie coûte deux choses : des heures, et la confiance dans vos propres chiffres. L'intégration API d'un site web supprime le geste, à condition de savoir où poser la frontière entre un connecteur d'étagère et du code. Cet article détaille les quatre scénarios de connexion, la ligne où les outils no-code s'arrêtent, et les trois questions à trancher avant d'écrire la moindre ligne.
Une API, concrètement
Une API (Application Programming Interface) est un contrat qui permet à deux logiciels d'échanger des données sans intervention humaine. Votre site demande « donne-moi le stock de la référence 4471 », l'ERP répond « 12 », et chacun ignore tout du fonctionnement interne de l'autre.
Ce contrat se décrit dans un format standard : OpenAPI, spécification maintenue par l'OpenAPI Initiative sous l'égide de la Linux Foundation. Un éditeur sérieux publie la description OpenAPI de son API. Quand elle n'existe pas, budgétez le temps de rétro-ingénierie que vos développeurs passeront à deviner, et demandez-vous ce que cette absence dit du reste.
Quatre scénarios d'intégration API pour un site web
Les projets se rangent presque toujours dans l'une de ces quatre catégories, par coût croissant.
- Votre site consomme une API externe. Paiement, transporteur, signature électronique, service de géocodage. Le fournisseur documente, vous appelez. C'est le cas le plus simple, celui de notre article sur l'intégration de Stripe Links dans Symfony.
- Votre site expose sa propre API. Vos données deviennent consommables par une application mobile, un back-office, un partenaire ou un assistant IA. Le site cesse d'être une île.
- Synchronisation bidirectionnelle avec le CRM ou l'ERP. Les deux systèmes détiennent une part de la vérité et doivent rester d'accord. C'est là que se logent les vraies difficultés, traitées plus bas.
- Passage par une plateforme d'automatisation. Zapier, Make ou n8n jouent les intermédiaires : vous câblez des déclencheurs et des actions sans développer.
Connecteurs no-code ou développement : où passe la ligne
Position que nous assumons, même quand elle nous fait perdre une mission : si votre besoin tient en un flux unidirectionnel, sans règle de gestion, avec un volume modeste, prenez Zapier ou Make et n'appelez personne. Payer un développeur pour recréer un connecteur formulaire vers CRM est un gaspillage.
Trois signaux indiquent que vous avez dépassé leur zone de confort. Le premier est la règle métier : dès qu'un champ se calcule au lieu de se recopier, la logique s'éparpille dans une interface graphique que personne ne sait relire six mois plus tard. Le deuxième est le volume, parce que ces plateformes facturent à l'opération et que la note grimpe vite quand chaque synchronisation en consomme plusieurs. Le troisième est le rattrapage d'erreur : quand l'ERP répond mal, un scénario no-code s'arrête et vous envoie un e-mail. Personne ne le lit.
Le calcul est le même que pour n'importe quel outil loué, et nous l'avons détaillé dans notre méthode de comparaison entre logiciel sur mesure et abonnement SaaS.
API Platform : ce que le socle vous donne sans le développer
Sur nos projets Symfony, exposer une API n'est pas un chantier séparé. API Platform génère, à partir des classes métier annotées, les points d'entrée REST, la description OpenAPI, une documentation navigable, la pagination, les filtres, la négociation de format (JSON, JSON-LD, GraphQL) et la gestion des erreurs.
Concrètement, la question « combien coûte l'API de notre site ? » change de nature. Le coût ne porte plus sur la plomberie HTTP, qui est fournie, mais sur ce qui vous est propre : les droits d'accès, les règles de validation, la forme des données exposées. C'est l'un des cinq critères de choix d'un socle technique, que nous avons développés dans notre article sur Symfony pour le site web d'une entreprise.
Nous avons construit sur cette base la marketplace ranksource, dont le catalogue annoncé dépasse 100 000 médias, et dont l'architecture est décrite en détail ici.
L'avis de Laurent, Lead Développeur, spécialiste back-end & IA chez EpickOne : « La première question que je pose en réunion de cadrage n'est jamais technique : qu'est-ce qui identifie un client chez vous, de bout en bout ? Sur notre projet de traitement documentaire pour un opérateur de ventes aux enchères, c'était l'immatriculation du véhicule, et rien d'autre ne tenait d'un bout à l'autre de la chaîne. Tant que cette clé n'est pas posée, l'intégration produit des doublons propres que personne ne sait réconcilier, et les équipes retournent au fichier Excel qu'on voulait supprimer. La deuxième question est plus désagréable : qui a raison quand les deux systèmes ne sont pas d'accord ? Si personne ne tranche en réunion, le code tranchera tout seul, et rarement dans le bon sens. »
CRM, ERP : les trois questions à trancher avant d'écrire du code
Quelle est la clé d'identité ? E-mail, SIRET, numéro de client, référence produit. Elle doit être stable, unique et présente des deux côtés. Un e-mail change, un SIRET peut désigner un établissement plutôt qu'une entreprise.
Qui détient la vérité, champ par champ ? L'adresse de facturation vient de l'ERP, les préférences de contact viennent du site, le statut commercial vient du CRM. Ce tableau se remplit en réunion, pas pendant le développement. Sans lui, deux systèmes se réécrivent mutuellement en boucle.
Quels sont les quotas de l'API cible ? Tous les éditeurs limitent le nombre d'appels par intervalle de temps. La réponse standard est un code HTTP 429 Too Many Requests, souvent accompagné d'un en-tête Retry-After qui indique le délai à respecter. Lisez la page « rate limits » de votre éditeur avant de promettre une synchronisation temps réel : elle contient parfois la vraie contrainte du projet.
Ce qui casse en production
Une intégration ne tombe presque jamais en panne le jour de la mise en ligne. Elle dérive.
Le doublon. Une requête part, le réseau coupe avant la réponse, le système rejoue l'appel, et vous avez deux commandes. La parade s'appelle l'idempotence : chaque opération porte un identifiant unique, et le serveur qui le reçoit deux fois n'exécute l'effet qu'une seule fois. Stripe l'implémente avec l'en-tête Idempotency-Key. Sur notre agent IA qui écrit dans l'ERP d'un opérateur automobile, cette règle — ne jamais rejouer deux fois le même effet — a structuré la conception avant toute considération de modèle.
Le webhook non vérifié. Un webhook est un appel entrant : le fournisseur prévient votre site qu'un événement a eu lieu, ce qui évite d'interroger son API en boucle. Point de vigilance : cette URL est publique. Vérifiez systématiquement la signature cryptographique envoyée par le fournisseur, sinon n'importe qui peut déclarer un paiement reçu.
L'échec silencieux. Un appel qui échoue doit être rejoué avec un délai croissant, puis mis de côté et signalé à un humain après plusieurs tentatives. Le composant Messenger de Symfony fournit ce mécanisme de file d'attente et de réessai. Ajoutez-y une journalisation de chaque échange et une alerte sur le taux d'erreur : une intégration sans supervision est une panne à retardement.
Cadrer le budget d'une intégration API de site web
Le devis d'une intégration ne se déduit pas du nombre de champs à synchroniser. Quatre postes portent l'essentiel de la charge, et deux d'entre eux se chiffrent avant le développement.
- La qualité de l'API cible. Documentation OpenAPI publiée, environnement de test disponible, quotas raisonnables : ces trois points font varier le budget d'un facteur important. Un ERP ancien sans API impose un export de fichiers, plus lent et plus fragile.
- Le nombre de sens de circulation. Une synchronisation bidirectionnelle coûte nettement plus qu'un aller simple, parce qu'elle oblige à gérer les conflits.
- La reprise de l'existant. Aligner les données déjà présentes des deux côtés est souvent le poste le plus sous-estimé du projet.
- Les tests et la supervision. Ils ne sont pas une option sur une chaîne qui tourne sans surveillance : les huit workflows qui relient une boîte mail à l'ERP, chez notre client opérateur de ventes aux enchères, sont couverts par 195 tests automatisés.
Exigez que ces quatre postes apparaissent séparément dans le devis. Un prestataire qui annonce un forfait global sur une intégration CRM n'a pas encore ouvert la documentation.
Par où commencer
Prenez le flux que vos équipes recopient le plus souvent, et mesurez-le sur une semaine : combien de fiches, combien de minutes, combien d'erreurs rattrapées. Ce chiffre-là est votre point de départ, et il vaut tous les arguments techniques. Vérifiez ensuite que l'outil cible publie une documentation d'API, puis tranchez la question de la clé d'identité. Le reste est du développement.
Pour situer l'intégration API d'un site web dans un projet complet, notre guide de la création de site web sur mesure déroule les étapes en amont ; sur le versant IA, notre article sur le Model Context Protocol et Symfony AI montre comment ces mêmes API deviennent des outils manipulables par un agent.
Vous hésitez entre un connecteur et du développement ? Nous réalisons une étude d'intégration : audit de l'API de votre CRM ou de votre ERP, tableau de la source de vérité champ par champ, scénarios chiffrés séparément, et recommandation écrite — y compris quand elle consiste à vous dire qu'un abonnement Make suffit. Demander une étude d'intégration.