La plupart des entreprises fonctionnent avec plusieurs systèmes qui ne se parlent pas. Votre logiciel comptable contient les factures. Votre CRM contient les clients. Votre site Web prend les commandes. Quelqu’un copie les données de l’un à l’autre à la main, et la copie arrive en retard ou contient des erreurs.
Une intégration est le logiciel qui fait en sorte que ces systèmes partagent leurs données par eux-mêmes. Cet article explique ce qu’est une API, ce qu’une intégration implique, ce qui fait varier le coût, et pourquoi les estimations pour ce type de travail tombent à côté plus souvent que pour une application neuve.
Ce qu’est une API
Une API (interface de programmation d’application) est un ensemble de règles qu’un logiciel publie pour que d’autres logiciels puissent lui parler. Au lieu d’un écran pour une personne, elle offre une porte pour un programme. Un programme demande les commandes d’un client, ou dit à l’autre de créer une facture, et la réponse revient dans un format structuré qu’une machine peut lire.
La plupart des systèmes modernes en ont une. Les outils comptables, les processeurs de paiement, les transporteurs, les CRM et les plateformes de marketing publient tous des API. Certaines sont bonnes : documentation claire, comportement stable, environnement de test. D’autres sont minces, mal documentées, ou changent sans préavis. La qualité de l’API de l’autre côté est le facteur qui pèse le plus sur la durée du travail, et vous n’avez aucun contrôle dessus.
Ce qu’est une intégration
Une intégration est le code qui se place entre deux systèmes ou plus et qui utilise leurs API pour déplacer des données. Elle comporte quelques éléments :
- Un déclencheur : un événement, comme une nouvelle commande, ou un horaire, comme toutes les heures
- Une correspondance : le champ X du système A devient le champ Y du système B, avec conversion des formats, des unités et des codes
- La gestion des erreurs : ce qui se passe quand un système est en panne, rejette un enregistrement ou renvoie quelque chose d’inattendu
- La journalisation et les alertes : pour savoir ce qui a été transféré, ce qui ne l’a pas été, et pourquoi
La correspondance a l’air d’être la partie difficile. En général, ce n’est pas le cas. C’est dans la gestion des erreurs que se trouve l’essentiel du travail, et c’est la partie que la plupart des gens oublient dans le budget.
Où se situe la conformité
Certaines intégrations existent parce qu’une règle l’exige. Les déclarations fiscales, les remises de paie, les registres financiers et les vérifications d’identité viennent tous avec des règles sur les données qui doivent circuler, vers où, dans quel format, et sur les traces que vous devez en garder. Nous construisons des logiciels de conformité pour cela : l’intégration, plus la piste de vérification et les contrôles que la règle exige. Le mécanisme est le même que pour toute autre intégration. La différence, c’est qu’un échec a un coût légal, donc la journalisation et la gestion des erreurs doivent être plus solides, et cela se voit dans l’estimation.
Ce qui fait varier le coût
Quand nous définissons la portée d’une intégration, quelques éléments comptent plus que tout le reste.
- Le nombre de systèmes et le nombre de directions. Un sens unique, de A vers B, est le plus simple. Une synchronisation dans les deux sens, où chaque côté peut modifier un enregistrement, double à peu près la logique et ajoute des règles pour les conflits.
- La qualité de chaque API. Une API documentée avec un environnement de test se travaille vite. Une API sans environnement de test, avec des limites de débit serrées ou un comportement étrange, coûte du temps d’exploration avant qu’une seule ligne de vrai code soit écrite.
- Le volume et le rythme. Quelques enregistrements par jour, c’est un autre problème que des milliers par minute. Le temps réel est plus difficile qu’un traitement par lots la nuit.
- La propreté des données. Si deux systèmes contiennent le même client sous des noms et des adresses différents, quelqu’un doit décider lequel a raison, et le code doit appliquer cette décision.
- Ce qui doit se passer en cas d’échec. Réessayer, sauter, mettre en attente pour révision, ou tout arrêter. Chaque réponse représente une quantité de travail différente.
Pourquoi les estimations se trompent
Les estimations d’intégration tombent à côté pour des raisons précises.
L’autre système n’est pas sous votre contrôle. Avec une application neuve, le comportement est défini par votre propre code. Une intégration dépend d’un logiciel que quelqu’un d’autre a construit, et vous n’apprenez comment il se comporte vraiment qu’en l’utilisant. La documentation décrit ce que l’API est censée faire. La réalité diffère sur de petits points, et chaque différence coûte du temps.
Les cas limites se cachent dans les vieilles données. Les cent premiers enregistrements passent. Le cent unième contient une date dans un format que personne n’attendait, ou un champ qui a été discrètement réaffecté il y a des années.
La portée grandit un champ à la fois. Pouvez-vous aussi envoyer le code de rabais ? Chaque demande est petite. Dix demandes, c’est un autre projet.
Personne n’est responsable des règles d’affaires. Quand deux systèmes ne s’entendent pas, lequel l’emporte ? Si personne ne peut répondre, le développeur devine, la supposition est fausse, et on s’en rend compte en production.
Les tests sont plus difficiles. On ne teste pas à la légère contre un système comptable en service. S’il n’y a pas d’environnement de test, vous construisez un substitut, ou vous testez très prudemment contre le vrai système.
[ !TIP] Avant de demander un prix à qui que ce soit, écrivez quelle est la source de vérité pour chaque type d’enregistrement, et ce qui doit se passer quand un transfert échoue. Ces deux décisions retirent la plus grande part de l’incertitude d’une estimation d’intégration.
Comment obtenir une meilleure estimation
- Dressez la liste de tous les systèmes concernés, en précisant si chacun a une API documentée et un environnement de test
- Tirez un échantillon de vraies données, y compris de vieux enregistrements, pas seulement des données récentes et propres
- Décidez quel système est la source de vérité pour les clients, les produits, les commandes et les paiements
- Écrivez les cas d’échec et qui doit en être averti
- Commencez par une direction et un type d’enregistrement, puis ajoutez le reste
Obtenir un chiffre
Notre estimateur donne une fourchette de prix en quelques minutes à partir de la grille tarifaire en vigueur. Il montre le coût de construction, les coûts mensuels, l’effort par rôle, un échéancier, et chaque hypothèse derrière le chiffre. Les hypothèses comptent le plus pour les intégrations, parce que c’est là que se trouve le risque. Lisez-les et dites-nous lesquelles sont fausses.
Les coûts mensuels comptent ici aussi. Une intégration n’est jamais tout à fait terminée. Les API changent, les systèmes sont mis à niveau, et les données dérivent. Un prix fixe convient quand les systèmes et la portée sont connus. Un bloc d’heures mensuel, avec un délai de réponse garanti, convient pour garder l’intégration en marche une fois en service. Nous faisons les deux, et nous acceptons des projets dès maintenant.
