Une intégration semble simple. Le système A détient les données, le système B en a besoin, et une API se trouve entre les deux. Sur un tableau blanc, c’est une seule flèche.
En pratique, cette flèche cache la plus grande partie du travail. Cet article explique ce qu’une intégration vous coûte réellement, pourquoi les estimations de ce type de travail dérapent si souvent, et ce que vous pouvez faire avant le début d’un projet pour rendre le chiffre plus fiable.
Ce que vous payez
Quand nous construisons une intégration, l’appel à l’API est la plus petite partie. Le coût se trouve dans tout ce qui l’entoure :
- Correspondance des données. Votre fiche client dans un système correspond rarement à celle de l’autre. Les champs ont des noms, des formats et des règles différents. Quelqu’un doit décider ce que signifie chaque champ et ce qui arrive quand il ne convient pas.
- Authentification. Les clés, les jetons et les permissions doivent être configurés, stockés de façon sécuritaire et renouvelés sans que rien ne se brise.
- Gestion des erreurs. Les réseaux tombent en panne. Les services s’arrêtent. Les requêtes sont refusées. Une bonne intégration sait quoi réessayer, quoi mettre en file d’attente et quoi signaler à une personne.
- Limites et cadence. Beaucoup d’API limitent la fréquence des appels. Déplacer un gros arriéré de fiches n’est pas le même travail que synchroniser un changement à la fois.
- Surveillance. Vous devez savoir quand la connexion cesse de fonctionner, idéalement avant vos clients.
- Conformité. Si les données comprennent des renseignements personnels ou financiers, vous pourriez avoir besoin de journaux d’audit, de contrôles d’accès et d’une trace claire de qui a modifié quoi. C’est là que le travail d’intégration et les logiciels de conformité se rejoignent.
Rien de cela n’apparaît dans le schéma à une flèche. Tout cela apparaît dans la réalisation.
Pourquoi les estimations dérapent
La plupart des problèmes d’estimation des intégrations viennent de la même source. La moitié du travail dépend d’un système que vous ne contrôlez pas.
L’autre côté est inconnu
Nous estimons bien notre propre code. Nous ne pouvons pas voir à l’intérieur du système d’un fournisseur. La documentation peut être périmée, incomplète ou absente. Un comportement que la documentation décrit d’une façon peut fonctionner autrement en production. Tant que personne n’a fait de vrais appels au vrai service, une partie de l’estimation relève de la supposition.
Les données sont plus désordonnées que prévu
Les fiches d’exemple semblent propres. Les vraies fiches contiennent des doublons, des champs vides, d’anciens formats et des valeurs que personne ne se rappelle avoir ajoutées. Nettoyer et réconcilier ces données est souvent le plus gros poste à lui seul, et il reste invisible tant qu’on ne regarde pas.
Il n’y a pas d’environnement de test
Certains services offrent un bac à sable où l’on peut tester librement. D’autres non, ou leur bac à sable se comporte autrement que le système réel. Sans bac à sable, les tests prennent plus de temps et demandent plus de soin.
La portée s’étend en périphérie
« Synchroniser les commandes » devient « synchroniser les commandes, les remboursements, les remboursements partiels et les commandes annulées puis rétablies ». Chaque cas est raisonnable. Ensemble, ils peuvent changer l’ampleur du travail.
L’API change plus tard
Les fournisseurs mettent à jour leurs API et retirent d’anciennes versions. Une intégration n’est pas terminée le jour de sa mise en service. Elle demande de l’entretien, et ce coût continu doit figurer au plan.
[ !TIP] Avant de demander une estimation à qui que ce soit, dressez la liste de tous les systèmes concernés, de la personne qui en est responsable et de la possibilité d’obtenir un accès de test. Cette seule page élimine plus d’incertitude que toute autre chose que vous pouvez faire.
Comment obtenir une estimation fiable
Vous pouvez réduire beaucoup la fourchette avant qu’une seule ligne de code ne soit écrite.
- Nommez les systèmes et le sens des données. Quel système fait foi pour chaque type de fiche ? Les données circulent-elles dans un sens ou dans les deux ?
- Partagez de vraies données d’exemple. Un petit export, dont les renseignements sensibles ont été retirés, nous en apprend plus qu’une description.
- Vérifiez tôt l’accès à l’API. Confirmez que vous pouvez obtenir des identifiants, un bac à sable s’il en existe un et la documentation à jour.
- Listez les cas limites que vous connaissez déjà. Retours, paiements refusés, comptes fusionnés. Tout ce que votre équipe règle à la main aujourd’hui.
- Décidez de ce qui arrive en cas d’échec. Le système doit-il réessayer en silence, alerter quelqu’un ou s’arrêter ? C’est autant une décision d’affaires qu’une décision technique.
- Notez les règles de conformité. Si un auditeur ou un organisme de réglementation posera des questions sur ces données, dites-le dès le départ.
Choisir une façon de travailler
L’ampleur de l’inconnu devrait influencer la façon dont vous payez le travail. Nous offrons trois façons de travailler, et chacune convient à un niveau de certitude différent.
Table : Associer la façon de travailler à l’intégration | Façon de travailler | Convient le mieux quand | | --- | --- | | Prix fixe pour une portée définie | Les systèmes, les données et les cas limites sont connus et consignés par écrit | | Une équipe au mois | Il y a plusieurs intégrations, ou la portée continuera de changer à mesure que vous apprenez | | Un bloc d’heures mensuel avec un temps de réponse garanti | L’intégration est en service et demande un suivi continu à mesure que les API changent |
Un prix fixe ne fonctionne bien que si la portée est vraiment définie. Si l’autre système demeure un mystère, imposer un chiffre fixe mène généralement à un prix gonflé ou à un changement pénible plus tard. Il vaut souvent mieux régler d’abord les inconnues, puis fixer le prix.
Voyez la fourchette pour votre projet
Notre estimateur vous donne une fourchette de prix en quelques minutes, à partir de notre grille tarifaire actuelle. Il présente le coût de réalisation, les coûts mensuels, l’effort par rôle, l’échéancier et chaque hypothèse derrière le chiffre. Lisez attentivement les hypothèses. Pour une intégration, c’est là que vous verrez ce qui est connu et ce qui ne l’est pas.
Si vous voulez en discuter, Atheron Network Labs est ouvert aux projets dès maintenant. Apportez votre liste de systèmes et nous vous dirons franchement où se trouve le risque.
