Vos systèmes se parlent entre eux, ou vos collaborateurs parlent à leur place.

Qu'est-ce que c'est ?

Les projets d'intégration avaient longtemps mauvaise réputation : chers, lents, fragiles. La cause était des bus de services Enterprise lourds, qui nécessitaient des experts dédiés et vacillaient à chaque mise à jour de système. Aujourd'hui, le monde est autre : les systèmes modernes ont des API standardisées, des plateformes d'intégration légères facilitent l'orchestration, et les approches modernes du génie logiciel font que les intégrations ne cassent plus à chaque update. Un projet d'intégration est aujourd'hui un projet normal, pas de la magie noire.

À quoi ça ressemble ?

Une entreprise avait mis deux mois et dépensé une somme à six chiffres il y a dix ans pour relier CRM et ERP, via un bus Enterprise qui a régulièrement posé problème ensuite. La même entreprise a refait l'intégration : en trois semaines, sans bus Enterprise, avec des liaisons API directes clairement documentées, un monitoring permanent et une base de code que n'importe quel développeur comprend en deux heures. Les coûts d'exploitation sont un dixième de l'ancienne solution. C'est l'évolution réelle du monde de l'intégration ces dernières années.

Pourquoi c'est important ?

Beaucoup d'entreprises hésitent sur les projets d'intégration à cause de vieilles expériences. C'est économiquement cher : vous acceptez les ponts manuels qui coûtent chaque semaine, alors que l'alternative aujourd'hui est nettement plus légère et moins chère qu'autrefois. L'intégration n'est plus en 2026 un projet de luxe. C'est une prestation de base qui s'amortit presque toujours rapidement.

Comment nous le construisons

Nous travaillons avec des approches d'intégration modernes et légères : contrats d'API clairs plutôt qu'infrastructures de bus, connexions directes ou orchestrations sobres selon la complexité, supervision sur chaque axe, gestion d'erreurs en principe de construction. Nous n'investissons pas dans de grandes infrastructures qui deviennent coûteuses plus tard. Nous investissons dans des liaisons propres, traçables, que n'importe quelle équipe de développement peut comprendre et adapter.

Cas d'usage typiques

• Entreprises avec paysage logiciel constitué historiquement sans échange de données propre
• Mittelstand après changement de système ou acquisition
• Entreprises avec ponts manuels coûtant du temps et produisant des erreurs
• Initiatives de digitalisation centrées sur l'efficacité des processus

Qu'est-ce que c'est ?

API-first signifie : nous relions les systèmes via leurs interfaces documentées (Application Programming Interfaces), pas via des scripts qui cliquent dans les interfaces utilisateur. Les API sont des accès structurés, stables, versionnés aux données et fonctions d'un système. Elles sont faites pour être utilisées par d'autres logiciels. Les interfaces utilisateur sont faites pour les humains, et changent à chaque refonte design.

À quoi ça ressemble ?

Un industriel a utilisé deux ans une solution transférant par automatisation d'écran des données entre un système métier et un outil de reporting. Elle cassait tous les deux à trois mois, car le système métier changeait son interface, et chaque réparation coûtait un jour d'arrêt. Nous avons remplacé la solution par une intégration API : l'API du système métier était stable, documentée et versionnée. Depuis la bascule, il y a eu trois mises à jour du système, pas une seule panne de l'intégration.

Pourquoi c'est important ?

L'automatisation d'écran est une solution de secours, pas un principe de construction. Elle n'est justifiée que si un système n'a vraiment aucune API, et encore faut-il que la décision soit prise en connaissance des inconvénients. Les solutions API sont plus robustes, plus rapides, moins chères à exploiter et nettement moins gourmandes en maintenance. Qui mise encore aujourd'hui à grande échelle sur l'automatisation d'écran construit une dette qui coûte des intérêts chaque mois.

Comment nous le construisons

Sur chaque projet, nous examinons d'abord quelles API sont disponibles dans votre paysage. Beaucoup de systèmes en ont plus que leurs utilisateurs ne le savent. Les versions modernes d'ERP, CRM et solutions métier sont presque toujours livrées avec des sets d'API étendus. Là où les API manquent, nous agissons avec pragmatisme : accès en lecture à la base de données, exports de fichiers structurés, au pire des ponts UI soigneusement construits avec plan de maintenance clair. La priorité est toujours : propre plutôt que rapide, durable plutôt que bâclé.

Cas d'usage typiques

• Systèmes cloud modernes (tous les CRM, ERP, outils marketing courants)
• Logiciels d'entreprise avec API REST ou GraphQL publiées
• Connexions SaaS (services de paiement, expédition, communication)
• Systèmes développés en interne avec interfaces documentées

Qu'est-ce que c'est ?

Dans toute entreprise, il existe des données vivant dans plusieurs systèmes : clients dans CRM et ERP, produits dans ERP et boutique, collaborateurs dans RH et contrôle d'accès. La synchronisation répond pour chacune de ces natures à trois questions : qui est la source directrice ? Dans quel sens circule un changement ? Que se passe-t-il en cas de conflit ? Sans réponses claires naissent des déserts de données où personne ne sait plus quelle version est bonne. Avec des réponses claires naissent des paysages propres.

À quoi ça ressemble ?

Un prestataire avait un scénario fréquent : les contacts étaient maintenus dans le CRM, mais aussi corrigés manuellement dans l'ERP lors de l'établissement d'une facture. Résultat : plus aucun enregistrement ne collait. Chaque système avait sa vérité. Nous avons défini pour chaque type de donnée une source directrice (contacts : CRM, données de facturation : ERP, infos bancaires : ERP), configuré la synchronisation en sens unique (CRM → ERP pour les contacts, pas de retour) et posé une règle claire pour les conflits (les changements de contact dans l'ERP sont renvoyés au CRM et passent par une étape de vérification). Trois mois plus tard, les données étaient consolidées, et cela reste ainsi, parce que la règle est claire et la machine la tient.

Pourquoi c'est important ?

Des données incohérentes ne sont pas qu'un irritant opérationnel. Elles coûtent des deals, parce que les clients reçoivent de mauvaises informations, et génèrent des risques juridiques en protection des données et en facturation. Elles sont en même temps invisibles tant que personne ne regarde : en surface, tout paraît normal, les problèmes n'apparaissent qu'aux cas limites, douloureux. Une synchronisation propre est peu spectaculaire, mais c'est économiquement l'une des plus grandes valeurs des projets d'intégration.

Comment nous le construisons

Nous commençons par une carte des données : quelle information vit où, qui la maintient, quel système est directeur. Cette carte est dessinée avec vous et documentée. C'est souvent la première fois qu'un tel aperçu existe. Sur cette base, nous définissons les règles de synchronisation par type de donnée et construisons la mise en œuvre. Les conflits ne sont jamais résolus silencieusement, mais rendus visibles et escaladés à un humain, jusqu'à ce qu'une règle soit établie.

Cas d'usage typiques

• Données clients entre CRM, ERP et outils marketing
• Données produits entre ERP, boutique et marketplace
• Données collaborateurs entre RH, IT et contrôle d'accès
• Données financières entre comptabilité, reporting et banking

Qu'est-ce que c'est ?

Il existe fondamentalement deux schémas. Intégration temps réel : chaque changement est transféré immédiatement, souvent via messages push entre systèmes. Intégration batch : les changements sont groupés dans des fenêtres (horaires, journaliers, hebdomadaires) et transférés. Le temps réel est plus cher en construction et en exploitation, le batch est plus simple mais avec décalage. La bonne décision dépend du cas d'usage, pas du souhait.

À quoi ça ressemble ?

Deux intégrations dans la même entreprise. Première : les nouveaux clients de la boutique doivent apparaître dans le CRM pour que le commerce puisse les contacter tout de suite. Le temps réel fait sens, chaque minute de retard coûte directement de la conversion. Seconde : les chiffres de vente produit doivent arriver quotidiennement dans l'outil de reporting. Le temps réel serait exagéré : l'outil est ouvert à 8h du matin, pas à 2h du matin. Un batch nocturne est plus robuste, plus simple à exploiter et moins cher. La décision était consciemment différente par intégration, non uniforme.

Pourquoi c'est important ?

Les équipes surestiment presque toujours le besoin de temps réel. Cela conduit à des solutions surdimensionnées, coûteuses en exploitation et compliquées à débugger dans les cas exceptionnels. Les intégrations batch ont longtemps été sous-estimées, alors qu'elles couvrent mieux une grande partie des cas réels : plus simples, plus robustes, moins chères, plus faciles à maintenir. Règle : temps réel seulement là où il apporte une valeur métier démontrable. Partout ailleurs : batch.

Comment nous le construisons

Nous décidons par intégration : que se passe-t-il si cette information arrive une heure plus tard ? Si la réponse est « rien », le batch est la bonne voie. Si la réponse est « perte de chiffre directe » ou « expérience client gênante », nous parlons temps réel. Entre les extrêmes, il existe beaucoup de chemins médians : des mini-batchs toutes les cinq ou quinze minutes sont souvent le compromis idéal.

Cas d'usage typiques

• Reprise de leads (souvent temps réel)
• Synchronisation de factures (souvent batch nocturne)
• Stocks (souvent mini-batch toutes les quelques minutes)
• Reporting et analytique (généralement batch quotidien)
• Confirmations de paiement (temps réel, par attente client)

Qu'est-ce que c'est ?

Dans un système unique, les erreurs sont généralement localisables : un bouton ne marche pas, une fonction jette une erreur. Dans les systèmes distribués naît une nouvelle classe : problèmes réseau, délais dépassés, deux systèmes à états différents, messages envoyés mais non reçus, actions à moitié réalisées. Sans gestion d'erreurs délibérée, toute intégration devient une bombe à retardement.

À quoi ça ressemble ?

Scénario fréquent : une intégration transfère la nuit des commandes à un prestataire. Une nuit, le prestataire est indisponible dix minutes. Une intégration mal construite marquerait les 200 commandes concernées comme perdues, et le matin, il y aurait une alerte support. Notre intégration détecte le problème, retente trois fois à intervalles croissants, réussit au troisième essai, et il n'y a aucune commande perdue. En cas de problème durable : message précis à l'équipe concernée avec exactement les opérations à vérifier, pas « tout est cassé » en bloc.

Pourquoi c'est important ?

Une mauvaise gestion d'erreurs est la raison principale pour laquelle les intégrations ont la réputation d'être fragiles. Une bonne gestion rend les intégrations ennuyeuses au sens positif : elles tournent, ce qui se passe est traçable, et les cas vraiment rares qui demandent l'attention humaine sont signalés précisément. Nous disons souvent à nos clients qu'« ennuyeux » est le compliment que nous souhaitons. Cela veut dire que plus personne n'a à parler de l'intégration.

Comment nous le construisons

Notre architecture d'erreurs a plusieurs couches. Relances automatiques en cas de problème temporaire (réseau, courtes pannes), à intervalles croissants. Pauses sûres en cas de problème durable, pour éviter tout dommage aux données. Messages d'escalade précis avec contexte complet, au lieu d'alarmes génériques. Capacité de reprise, pour qu'après une interruption on reparte exactement là où l'erreur est survenue, pas depuis le début. Tout journalisé, tout traçable, calibré par intégration.

Cas d'usage typiques

• Intégrations financières avec zéro tolérance à la perte de données
• Connexions proches de la production avec exigence temps réel
• Intégrations de communication avec temps de réponse garantis
• Workflows multi-étapes avec dépendances entre systèmes

Qu'est-ce que c'est ?

Les systèmes legacy, des logiciels anciens tournant en production depuis des années, sont souvent l'épine dorsale de l'entreprise et en même temps la plus grande douleur d'intégration. Ils ont peu ou pas d'API modernes, leur documentation est lacunaire, leurs exploitants sont prudents. Les remplacer n'est généralement pas une option réaliste : trop cher, trop risqué. Les embrasser et les encastrer dans des paysages modernes est la voie pragmatique que nous recommandons presque toujours.

À quoi ça ressemble ?

Une entreprise utilise depuis plus de vingt ans un système métier tournant sur sa propre base de données, sans API moderne. Le remplacement a été envisagé à plusieurs reprises, et toujours reporté, car les coûts seraient incalculables. Nous avons construit un pont d'intégration : une couche intermédiaire svelte lit en lecture seule directement dans la base, prépare les données de manière structurée et les expose sous forme d'API moderne pour tous les autres systèmes. L'accès en écriture passe de façon contrôlée par les mécanismes d'import existants. Résultat : le système reste inchangé et stable, tout le reste peut s'y connecter avec des moyens modernes. Le remplacement n'est plus urgent, et c'est très bien.

Pourquoi c'est important ?

Beaucoup d'entreprises sont prises entre deux extrêmes : la pression de remplacer le legacy (cher, risqué, lent) et la frustration de ne pas pouvoir le connecter à un logiciel moderne (cher, freinant). La troisième voie, respecter le legacy et l'encastrer par des ponts d'intégration intelligents, est souvent oubliée mais économiquement supérieure dans la plupart des cas. Nous avons des clients dont un système de trente ans est aujourd'hui mieux intégré que tel outil cloud.

Comment nous le construisons

Nous travaillons avec tous les chemins d'accès disponibles : API officielles (si présentes), accès base de données en lecture (sur modèles stables et avec validation claire), exports de fichiers structurés, interfaces protocolaires pour systèmes industriels anciens, et au pire des automatisations UI soigneuses avec stratégie de maintenance documentée. Toujours avec le principe : le legacy n'est pas modifié, seulement interrogé ou alimenté de façon contrôlée.

Cas d'usage typiques

• Mittelstand avec systèmes métier historiquement constitués
• Industrie avec anciens pilotages machines
• Santé et secteur public avec systèmes longue durée
• Entreprises après acquisition avec paysage logiciel hétérogène

Qu'est-ce que c'est ?

Toute intégration signifie qu'un système accorde à un autre un accès : à des données, à des fonctions, souvent à des informations sensibles. La sécurité à ces endroits répond à trois questions : qui a le droit de faire quoi (authentification et rôles), quelles données circulent réellement (minimisation, chiffrement, journalisation), que se passe-t-il en cas d'abus ou de panne (détection, confinement, restauration) ? Cela paraît technique, mais c'est au fond ce que votre IT et votre délégué à la protection des données vous recommanderont.

À quoi ça ressemble ?

Une intégration entre boutique et ERP transfère données clients et lignes de commande. Nous vérifions : la boutique a-t-elle vraiment besoin d'un accès aux données clients complètes dans l'ERP (date de naissance, notes internes) ? Non : une vue réduite sans ces champs suffit. Nous construisons un accès API propre et minimal pour la boutique, avec seulement ce qui est nécessaire. Cet accès passe par une authentification séparée, est journalisé et serait immédiatement bloqué en cas d'anomalie. La minimisation des données comme principe de sécurité économise des discussions avec la protection des données et réduit la surface d'attaque en même temps.

Pourquoi c'est important ?

Les intégrations ont longtemps été le point faible des architectures de sécurité. Accès trop larges, clés distribuées généreusement, transferts non chiffrés : autant de classiques évitables. Dans l'espace DACH s'ajoute : le RGPD exige explicitement une vérification des données réellement transférées. Qui ne peut le documenter aura des comptes à rendre au prochain contrôle. La sécurité aux frontières d'intégration est donc à la fois devoir technique et condition réglementaire.

Comment nous le construisons

Nous travaillons par défaut avec des comptes d'accès dédiés par intégration (pas de « logins admin » partagés), des droits minimaux (seulement ce dont l'intégration a besoin), un chiffrement des transferts entre tous les systèmes, une gestion centralisée des clés API avec plan de rotation régulier, la journalisation de chaque action d'accès et la surveillance automatique des anomalies. Pour les secteurs régulés, nous ajoutons des contrôles de conformité spécifiques.

Cas d'usage typiques

• Intégrations avec données personnelles (obligation RGPD)
• Intégrations financières avec accès aux informations de paiement
• Intégrations santé avec données spécialement protégées
• Intégrations avec partenaires externes (fournisseurs, prestataires)

Qu'est-ce que c'est ?

Les intégrations vieillissent autrement que les logiciels normaux. Chacun des systèmes connectés évolue : nouvelles versions, API modifiées, nouvelles exigences de sécurité. Si l'intégration ne suit pas, elle finira par casser. La maintenabilité n'est donc pas un luxe, c'est un devoir économique. Une intégration parfaitement construite que personne ne comprend plus au bout de deux ans est pire qu'une solution simple que tout le monde peut lire.

À quoi ça ressemble ?

Nous avons plusieurs clients qui exploitent depuis plus de cinq ans des intégrations que nous avons construites au départ. Toutes tournent stablement, toutes ont été adaptées plusieurs fois dans l'intervalle (nouvelles versions, nouveaux champs, nouvelles exigences de conformité). Chaque adaptation s'est faite en quelques jours, parce que les solutions étaient documentées, structurées et construites selon les principes modernes du génie logiciel. Les entreprises qui voient les intégrations comme « construire une fois, ne plus y toucher » construisent involontairement des dettes qui coûteront cher plus tard.

Pourquoi c'est important ?

Beaucoup de prestataires construisent des intégrations superbes à la mise en ligne, mais qui demandent dans trois ans un développement complet à neuf, parce que plus personne ne comprend le code ni ne sait toucher aux changements. C'est de l'argent gaspillé. Les bonnes architectures d'intégration vieillissent avec dignité : elles s'adaptent, se vérifient, se reprennent par d'autres développeurs. La différence n'apparaît qu'avec les années, mais elle est alors très nette.

Comment nous le construisons

Nous construisons les intégrations avec les mêmes standards que pour les logiciels produit : code versionné dans Git, tests automatiques par intégration, documentation claire sur ce qui circule et pourquoi, facilité de modification des champs ou formats, journalisation avec outils d'analyse, capacité de rollback en cas de problème. Et nous investissons dans une documentation de reprise qu'une équipe de développement moyennement expérimentée puisse comprendre et reprendre en peu de temps. Le verrouillage fournisseur nous est étranger. Vous devez avoir la liberté de travailler avec qui vous voulez.

Cas d'usage typiques

• Intégrations longue durée en production
• Intégrations critiques où les pannes coûtent cher
• Entreprises avec équipe interne de développement en croissance
• Projets avec exigence de conformité à la traçabilité