Deux logiciels échangent un contact pendant une démonstration et le projet semble terminé. En fonctionnement réel, une modification arrive deux fois, un champ manque ou la destination reste indisponible. L’intégration doit alors décider quoi conserver, quoi rejouer et qui prévenir. Pour une entreprise qui achète un connecteur ou une prestation API, ces situations font partie du service attendu. La valeur ne se mesure pas seulement au premier transfert réussi, mais à la capacité de comprendre et de reprendre les opérations lorsqu’elles s’écartent du parcours idéal.
En bref : définir la donnée de référence, les identifiants, les reprises et le suivi des erreurs permet de comparer les intégrations sur leur fonctionnement quotidien.
Choisir quel système fait foi pour chaque information
Un CRM, un logiciel comptable et un outil de support peuvent contenir le même client avec des champs différents. Le projet doit décider où chaque information est créée et qui peut la modifier. Une synchronisation bidirectionnelle sans règles peut renvoyer les changements d’un système à l’autre ou écraser une correction. La carte des flux doit décrire les responsabilités, pas seulement relier des logos.
Les identifiants demandent une attention particulière. Un nom ou une adresse électronique peut changer ; une référence interne peut être stable dans un seul système. Le connecteur doit expliquer comment il reconnaît un dossier déjà transmis. Le rapprochement des données existantes doit aussi être préparé, surtout si les outils ont été utilisés séparément pendant plusieurs années.
Les champs obligatoires et les valeurs possibles doivent être comparés. Une information acceptable dans la source peut être refusée par la destination. Le prestataire doit montrer ce qui se passe dans ce cas et comment la correction rejoint ensuite le flux. Ajouter une valeur arbitraire pour faire passer tous les dossiers peut créer des erreurs métier difficiles à repérer.
Comprendre le rythme des échanges
Une intégration peut consulter régulièrement une API ou recevoir des notifications d’événement selon les outils. Ces mécanismes ne présentent pas les mêmes délais ni les mêmes limites. Le projet doit définir ce qui doit être visible immédiatement et ce qui peut attendre. L’expression « temps réel » doit être rapprochée du fonctionnement réellement mis en œuvre.
Des notifications peuvent être transmises plusieurs fois ou arriver dans un ordre différent de celui attendu selon le service. L’intégration doit traiter ce comportement sans répéter une opération métier de manière injustifiée. Les mécanismes d’identification et de reprise doivent être expliqués par le prestataire. L’entreprise n’a pas besoin d’écrire elle-même le code pour demander une démonstration de ces situations.
Les volumes et les limites d’accès doivent être évalués. Une reprise de milliers de dossiers peut se comporter autrement qu’un transfert quotidien limité. Le fournisseur doit préciser les contraintes connues et la méthode utilisée pour reprendre un retard. Le dimensionnement doit tenir compte des imports initiaux et des pics prévisibles, pas uniquement du fonctionnement moyen.
Prévoir la reprise après une interruption
Lorsqu’un système ne répond pas, il faut conserver les opérations à traiter ou permettre de les retrouver selon la méthode retenue. Le responsable doit savoir ce qui attend, depuis quand et pourquoi. Une alerte générique « synchronisation échouée » ne permet pas de distinguer un incident ponctuel d’un ensemble de dossiers définitivement oubliés.
La reprise doit éviter de créer des doublons. Le test peut simuler un envoi dont le résultat n’a pas été confirmé, puis demander sa répétition. Il faut vérifier ce qui apparaît dans la destination et comment le prestataire reconnaît l’opération. Les règles doivent correspondre aux actions métier : une mise à jour de fiche et une création de commande n’ont pas les mêmes conséquences.
Les utilisateurs doivent disposer d’une procédure de correction compréhensible. Certaines erreurs peuvent être résolues en complétant une donnée ; d’autres demandent une intervention technique. Le support doit pouvoir consulter les informations nécessaires sans exposer inutilement des données sensibles dans les journaux. Les accès aux diagnostics doivent suivre les rôles prévus.
Les échanges doivent suivre le processus qu’ils servent. Notre article sur l’organisation d’un logiciel d’interventions terrain offre un exemple concret : transmettre un rendez-vous ne suffit pas si le dossier, les pièces et le statut ne rejoignent pas les bonnes personnes.
Acheter un flux maintenable et vérifiable
Le devis doit préciser les systèmes, les versions ou interfaces concernées, les champs et les événements pris en charge. Il faut connaître les limites du connecteur standard et le périmètre du développement spécifique. Une fonction proposée par l’éditeur ne couvre pas nécessairement le processus particulier de l’entreprise. Les adaptations doivent être documentées avec leur responsabilité de maintenance.
Un changement d’API, de champ ou de droit peut perturber une intégration auparavant stable. Le contrat doit expliquer qui surveille ces évolutions et comment les corrections sont traitées. Les comptes techniques et les secrets d’accès doivent être administrés selon une organisation connue. Une connexion ne devrait pas dépendre durablement du compte personnel d’un salarié parti.
La recette doit comparer les données source et destination sur des scénarios définis : création, modification, erreur et reprise. Les résultats doivent être conservés pour pouvoir réévaluer le flux après un changement. Cette méthode transforme l’intégration en service observable, plutôt qu’en automatisation dont le fonctionnement n’est découvert que lorsque deux équipes remarquent des informations contradictoires.
