Intégrer plutôt que remplacer : relier vos outils sans tout refaire
Le scénario est presque toujours le même. Deux outils ne se parlent pas, quelqu’un ressaisit entre les deux, l’écart de données finit par se voir chez un client. On en conclut qu’il faut remplacer l’un des deux — souvent le plus ancien, parfois les deux — par une solution unique qui « fera tout ».
C’est la conclusion la plus coûteuse, et ce n’est presque jamais la bonne. Le problème posé n’est pas un problème de logiciel : c’est un problème de communication entre logiciels.
Pourquoi le remplacement est le réflexe le plus cher
Remplacer un outil qui fonctionne, c’est refaire tout ce qu’il faisait bien pour corriger la seule chose qu’il faisait mal. On paie la reprise de l’historique, la reconstruction des habitudes, la formation, les mois pendant lesquels les équipes travaillent moins bien, et le risque de découvrir en cours de route une fonction que personne n’avait mentionnée parce qu’elle allait de soi.
Et au bout, la question d’origine peut très bien rester entière : le nouvel outil ne parlera pas davantage aux autres systèmes que l’ancien.
Ce qu’une intégration règle réellement
Relier deux outils, c’est faire circuler une information dans un sens ou dans les deux, automatiquement, selon des règles écrites. Cela règle exactement quatre choses, et il faut vérifier que votre problème en fait partie :
- la double saisie, quand la même donnée est tapée à deux endroits ;
- l’écart entre systèmes, quand deux outils affichent deux vérités ;
- le délai, quand une information met un jour à arriver là où elle sert ;
- l’oubli, quand la transmission dépend de quelqu’un qui peut être absent.
Si votre problème est dans cette liste, une intégration suffit. S’il est ailleurs — un outil qui ne sait pas faire ce qu’on lui demande, une interface que personne ne supporte plus — alors c’est bien un sujet de remplacement, et il faut l’assumer comme tel.
Remarque : la question à poser en réunion n’est pas « faut-il changer d’outil ». C’est : « quelle information n’arrive pas au bon endroit ? » La réponse départage les deux chemins en quelques minutes.
Les trois questions avant de se lancer
L’outil sait-il parler ? La plupart des logiciels professionnels récents exposent un moyen d’échanger avec l’extérieur. Certains outils anciens, ou très spécialisés, n’ont rien — et il faut alors passer par des chemins plus fragiles, ce qui change le calcul.
Dans quel sens, et qui fait foi ? C’est la question qui fait échouer les intégrations mal préparées. Si les deux systèmes peuvent modifier la même donnée, il faut décider lequel a raison en cas de conflit. Cette décision est métier, pas technique, et personne d’autre que vous ne peut la prendre.
À quelle fréquence ? Une donnée qui circule une fois par nuit ne coûte pas la même chose qu’une donnée qui circule à la seconde. Beaucoup de besoins présentés comme « en temps réel » se contentent très bien d’un quart d’heure, et l’écart de coût est considérable.
Ce que ça change pour un décideur
Une intégration se chiffre, se livre et se vérifie sur un périmètre court — quelques semaines, pas un exercice budgétaire. Elle ne demande pas de conduite du changement, puisque personne ne change d’outil. Et surtout, elle est réversible : si l’organisation évolue, on modifie la circulation sans toucher aux systèmes.
C’est aussi une décision qui n’interdit rien pour la suite. Une entreprise qui intègre aujourd’hui reste libre de remplacer un outil dans trois ans — et elle le fera mieux, parce qu’elle aura documenté au passage ce qui circule réellement entre ses systèmes.
Ce qu’il faut faire
- Nommez l’information qui n’arrive pas au bon endroit, en une phrase.
- Dites dans quel sens elle doit circuler, et lequel des deux systèmes fait foi.
- Vérifiez que les deux outils savent parler à l’extérieur, et sinon lequel bloque.
- Fixez une fréquence réaliste, et résistez au « temps réel » par défaut.
- Chiffrez cette intégration avant de chiffrer un remplacement, pour comparer deux devis et non un seul.
Le point 5 est celui qu’on saute, et c’est celui qui fait économiser le plus. .
Si la conclusion est malgré tout qu’il faut un outil neuf, la frontière entre Power Apps et un développement sur Azure se pose alors, et la question de la propriété doit être réglée dès le premier rendez-vous.
Les sources Microsoft
Ce qu'un article ne peut pas savoir
Un article décrit ce qui vaut pour tout le monde. Ce qui change d'une organisation à l'autre, c'est l'inventaire : quelles applications, quels comptes, quels équipements sont réellement concernés chez vous. C'est l'inventaire qui décide de l'effort, et il ne se répond pas sur une page.
Vous parlez aux ingénieurs qui feraient le travail, pas à un intermédiaire. Réponse sous 24 heures ouvrées.
Vérifier ce qui est encore vrai
Les dates annoncées sont parfois repoussées, les produits changent de nom, les conditions évoluent. Le blog suit ces sujets au fil du temps : quand une règle change, un nouvel article le dit.
Chercher un sujet dans le blogDans le même dossier
Trois articles du même sujet. Le blog en compte 149, tous en accès libre.