Quand une entreprise lance un projet d'application web sur mesure, l'attention se concentre naturellement sur les fonctionnalités, l'interface, le design. Mais le vrai défi — celui qui conditionne le succès ou l'échec du projet — se joue ailleurs : dans la connexion avec le système d'information existant.
ERP, CRM, SIRH, outils de facturation, plateformes e-commerce, bases de données métier… Une application isolée n'a pas de valeur. Sa valeur naît de sa capacité à s'intégrer dans un écosystème déjà en place, souvent hétérogène, parfois vieillissant, toujours critique pour l'activité.
Pourquoi l'intégration est le vrai défi
Une application sur mesure est rarement la première brique du SI. Elle arrive dans un paysage où des systèmes fonctionnent depuis des années, avec leurs données, leurs processus, leurs habitudes utilisateur. L'ignorer, c'est construire un îlot déconnecté que personne n'utilisera — ou pire, qui imposera des doubles saisies.
Le SI existant est rarement prêt
Dans la théorie, les systèmes modernes exposent des API REST documentées et versionnées. Dans la pratique, on découvre des ERP sans API (ou avec une API SOAP mal documentée), des exports CSV manuels, des bases de données accessibles uniquement en lecture directe, des fichiers déposés sur un serveur FTP chaque nuit à 3h du matin.
Ces contraintes ne sont pas des anomalies. C'est la réalité de la majorité des SI d'entreprise. Le projet sur mesure doit s'y adapter, pas l'inverse.
La dette d'intégration est invisible
Contrairement à un bug visible ou une fonctionnalité manquante, les problèmes d'intégration sont insidieux. Des données désynchronisées entre deux systèmes, un flux qui échoue silencieusement un dimanche soir, un mapping de données qui ne couvre pas un cas limite… Ces problèmes s'accumulent sans alerter personne jusqu'au jour où un écart significatif est découvert par un utilisateur.
Cartographier l'existant
Avant d'écrire la moindre ligne de code, il faut cartographier le SI existant avec une question simple pour chaque système : comment peut-on échanger des données avec lui ?
Inventaire des systèmes
Listez tous les systèmes qui détiennent ou consomment des données pertinentes pour le projet. Pas seulement les systèmes principaux (ERP, CRM), mais aussi les outils périphériques : tableurs partagés, bases Access, applications métier développées en interne il y a dix ans, SaaS connectés par des exports manuels.
Pour chaque système, documentez : le type de données qu'il détient, la fréquence de mise à jour, le nombre d'utilisateurs, la criticité pour l'activité et le responsable technique.
Capacités d'intégration réelles
Pour chaque système identifié, évaluez les capacités d'intégration réelles, pas théoriques. Ce n'est pas parce qu'un éditeur annonce une API REST que celle-ci couvre vos besoins.
- API REST/GraphQL — le cas idéal. Vérifiez la couverture fonctionnelle, les limites de rate limiting, la qualité de la documentation, les mécanismes d'authentification
- API SOAP/XML-RPC — fonctionnel mais verbeux. Nécessite souvent un wrapper pour normaliser les échanges avec le reste du SI
- Export de fichiers — CSV, XML, JSON déposés sur un SFTP ou un partage réseau. Simple mais fragile : pas de notification, pas de gestion d'erreur native, dépendance au format du fichier
- Accès base de données — lecture directe dans la base du système source. Performant mais dangereux : couplage fort au schéma interne, risque de blocage si le schéma évolue, aucune garantie de stabilité
- Aucune capacité native — certains systèmes ne proposent rien. Il faut alors envisager du screen scraping, des macros, ou accepter une saisie manuelle
Les quatre stratégies d'intégration
Une fois l'existant cartographié, il faut choisir comment connecter les systèmes entre eux. Quatre grandes stratégies existent, chacune avec ses compromis.
Point à point
Chaque système communique directement avec les autres. L'application A appelle l'API du système B, qui pousse vers le système C. C'est simple à mettre en place pour deux ou trois systèmes, mais le nombre de connexions croît de manière quadratique. Avec cinq systèmes, on gère potentiellement vingt flux. La maintenance devient un cauchemar.
Middleware / bus de messages
Un composant central — RabbitMQ, Apache Kafka, Amazon SQS — sert d'intermédiaire. Les systèmes publient des événements et s'abonnent aux événements des autres. Le découplage est le bénéfice principal : chaque système ne connaît que le bus, pas les autres systèmes. Ajouter un nouveau consommateur ne nécessite aucune modification des producteurs existants.
ESB (Enterprise Service Bus)
L'ESB ajoute de l'orchestration au bus de messages. Il transforme les données, route les messages selon des règles métier, gère les erreurs et les retries. C'est puissant mais lourd à mettre en place et à maintenir. Réservez-le aux SI complexes avec des dizaines de systèmes et des flux de transformation sophistiqués.
iPaaS (Integration Platform as a Service)
Les solutions iPaaS (MuleSoft, Boomi, Workato, Make, n8n) proposent une plateforme cloud avec des connecteurs préconfigurés. Le time-to-market est rapide, la maintenance est déléguée. En contrepartie, vous dépendez d'un fournisseur, les coûts augmentent avec le volume, et les cas d'usage complexes atteignent vite les limites de la plateforme.
Patterns de synchronisation
Quelle que soit la stratégie d'intégration choisie, il faut définir comment les données circulent entre les systèmes. Plusieurs patterns coexistent, souvent au sein du même projet.
Temps réel vs batch
La synchronisation temps réel (webhooks, événements, API push) est idéale pour les données critiques : un paiement confirmé, un stock mis à jour, un utilisateur désactivé. La synchronisation batch (cron, ETL, import de fichiers) convient aux données moins urgentes : catalogue produit quotidien, rapport de ventes hebdomadaire, export comptable mensuel.
Ne forcez pas le temps réel partout. Un batch bien conçu est plus simple, plus fiable et plus facile à monitorer qu'une intégration temps réel mal maîtrisée.
Source de vérité unique
Pour chaque donnée, identifiez le système maître — celui qui fait autorité. Le CRM est maître des coordonnées client. L'ERP est maître des prix et des stocks. L'application sur mesure est maître des données qu'elle crée.
Les autres systèmes consomment cette donnée en lecture. Si un système secondaire doit modifier une donnée, il envoie une demande au système maître, qui applique le changement et notifie les autres. Sans source de vérité unique, les conflits de données sont inévitables.
Gestion des conflits et idempotence
Malgré les meilleures intentions, des conflits surviennent. Deux systèmes modifient la même donnée simultanément. Un message est traité deux fois. Un flux échoue à mi-parcours.
L'idempotence est le filet de sécurité : traiter un même événement deux fois doit produire le même résultat. Utilisez des identifiants uniques par événement et vérifiez qu'ils n'ont pas déjà été traités avant d'agir. Pour les conflits réels, définissez une stratégie explicite : last-write-wins, merge ou rejet avec notification.
Contraintes techniques courantes
L'intégration d'un SI existant réserve des surprises techniques que l'expérience apprend à anticiper.
Formats hétérogènes
Un système envoie du JSON, un autre
du XML, un troisième du CSV
avec un séparateur point-virgule, un quatrième
du SOAP enveloppé dans trois couches
de namespaces. Chaque intégration nécessite
un adaptateur de format. Normalisez les données
vers un format interne unique dès l'entrée
dans votre application.
Authentification disparate
API key pour l'un, OAuth2 pour l'autre, certificat client pour le troisième, login/mot de passe en Basic Auth pour le quatrième. Centralisez la gestion des credentials dans un coffre-fort (Vault, AWS Secrets Manager) et abstraisez l'authentification derrière une couche uniforme.
Volumétrie et timeouts
Un export ERP de 500 000 lignes ne se traite pas comme une notification de webhook. Dimensionnez vos traitements pour la volumétrie réelle, pas pour celle du prototype. Prévoyez des timeouts généreux pour les systèmes lents, des traitements par lots pour les gros volumes, et des mécanismes de reprise pour les imports interrompus.
Mapping de données
Le même concept porte des noms différents dans chaque système. Le « client » du CRM est un « tiers » dans l'ERP et un « account » dans le SaaS anglophone. Les identifiants ne correspondent pas. Les formats de date varient. Les listes de valeurs ne se recouvrent pas exactement.
Le mapping de données est le travail le plus ingrat de l'intégration, mais aussi le plus critique. Documentez chaque correspondance dans une table de mapping explicite. Ne laissez jamais un mapping implicite dans le code.
Les erreurs classiques
Certaines erreurs d'intégration reviennent de projet en projet. Les connaître permet de les éviter.
Couplage fort entre systèmes
Quand l'application sur mesure appelle directement les tables de l'ERP, toute mise à jour de l'ERP risque de casser l'intégration. Interposez toujours une couche d'abstraction — API, vue SQL, fichier d'export — pour isoler les systèmes les uns des autres.
Synchronisation bidirectionnelle mal maîtrisée
La synchronisation bidirectionnelle — où chaque système peut modifier la donnée et la pousser vers l'autre — est un terrain miné. Sans source de vérité claire, les conflits s'accumulent. Sans horodatage fiable, impossible de déterminer quelle version prime. Évitez-la autant que possible. Si elle est incontournable, investissez massivement dans la gestion de conflits et le monitoring.
Absence de monitoring
Un flux d'intégration qui échoue silencieusement est pire qu'un flux qui n'existe pas. Au moins, sans flux, les utilisateurs savent qu'ils doivent saisir manuellement. Avec un flux en erreur, ils font confiance à des données obsolètes ou incomplètes sans le savoir.
Pas de fallback
Quand un système source est indisponible, que se passe-t-il ? Si la réponse est « l'application plante » ou « les données disparaissent », c'est un problème de conception. Prévoyez un mode dégradé : cache local, données en lecture seule, message explicite à l'utilisateur.
Monitoring et observabilité
L'intégration ne s'arrête pas au déploiement. Un SI vivant évolue en permanence : mises à jour, changements de schéma, pics de charge, pannes temporaires. Sans monitoring dédié, les problèmes d'intégration sont découverts par les utilisateurs — toujours trop tard.
Logs structurés
Chaque flux d'intégration doit produire des logs structurés : système source, système cible, type d'opération, nombre d'enregistrements traités, durée, statut (succès/échec), identifiant de corrélation. Ces logs permettent de reconstituer le parcours d'une donnée à travers les systèmes.
Alerting sur les échecs
Configurez des alertes sur les échecs de synchronisation, mais aussi sur les anomalies : un flux qui traite habituellement 1 000 enregistrements et qui en traite subitement 0 est suspect, même s'il ne génère pas d'erreur technique. Un écart de plus de 10 % par rapport à la moyenne mérite une investigation.
Tableau de bord d'intégration
Un tableau de bord centralisé qui affiche l'état de chaque flux en temps réel : dernier succès, nombre d'erreurs sur les dernières 24 heures, volume traité, latence moyenne. C'est l'outil qui transforme l'intégration d'une boîte noire en un composant observable et maîtrisé.
SLA par flux
Définissez un SLA pour chaque flux : fréquence attendue, latence maximale tolérée, taux d'erreur acceptable. Un flux de synchronisation de stock avec un SLA de 5 minutes n'est pas géré comme un export comptable mensuel. Les SLA permettent de prioriser les interventions et de dimensionner le monitoring.
Réussir l'intégration
Connecter un SI existant à une application sur mesure est un travail d'architecte autant que de développeur. Il faut comprendre les systèmes en place, accepter leurs contraintes, choisir les bons patterns et investir dans le monitoring dès le premier jour. C'est rarement le sujet le plus visible du projet, mais c'est celui qui détermine si l'application sera réellement utilisée — ou si elle restera un outil de plus, déconnecté du reste.
Chez x10, nous accompagnons les DSI et les CTO dans l'intégration de leurs nouveaux outils avec leur SI existant. De l'audit de l'existant jusqu'au monitoring en production, en passant par la conception des flux et le choix des patterns de synchronisation. Besoin d'un audit de vos processus informatiques ou d'un développement sur mesure connecté à votre SI ? Parlons-en.