Une intégration API peut fonctionner chaque jour et rester dangereuse : doublons absorbés manuellement, secrets jamais tournés, messages perdus sans alerte, quotas proches de la limite et dépendance à une personne qui sait relancer le bon traitement.
Un audit d’intégration API ne note pas seulement la qualité du code. Il vérifie si le flux produit la bonne décision métier, résiste aux échecs, laisse des preuves et peut évoluer à un coût maîtrisé.
Cette scorecard organise l’audit en douze axes avec preuves et tests. Elle permet de comparer plusieurs intégrations, de définir des veto et de choisir entre maintien, sécurisation ciblée, refonte progressive ou remplacement.
La note finale n’a de valeur que si elle renvoie à des observations reproductibles. Une architecture élégante sur diagramme ne compense pas l’impossibilité de rejouer un incident sans risque.
Cadrer le mandat et la population
Le mandat liste flux, environnements, partenaires, données, utilisateurs et processus concernés. Il précise l’événement de départ, le résultat attendu et la conséquence d’un retard ou d’une erreur.
La période d’observation doit inclure pics, incidents et opérations de rattrapage. Un audit réalisé uniquement sur une semaine calme sous-estime les risques de capacité et de reprise.
Les limites sont explicites : conformité approfondie, tests d’intrusion ou audit fournisseur peuvent demander des expertises séparées. La scorecard signale le besoin sans prétendre le couvrir superficiellement.
Relier les flux à la valeur métier
Chaque intégration est reliée à une décision : créer une commande, enrichir un dossier, accorder un accès, calculer une facture ou synchroniser un stock. On mesure volume, délai utile, taux de succès métier et coût de l’échec.
Les contournements sont comptés : ressaisie, export, rapprochement, relance, ticket et contrôle humain. Une intégration techniquement stable peut détruire sa valeur si elle déporte les exceptions sur les opérations.
La criticité dépend d’abord de l’impact métier, financier et réglementaire, pas de la fréquence. Un flux mensuel de paie ou de clôture peut exiger plus de garanties qu’un enrichissement exécuté chaque minute.
Inventorier contrats et dépendances
L’inventaire rassemble points d’accès, événements, versions, schémas, authentification, bibliothèques, files, tâches, stockage et consommateurs. Les appels indirects, les webhooks et les opérations manuelles de rattrapage sont également inclus.
Chaque contrat possède un responsable, une documentation, une politique de compatibilité et un environnement de test. Une dépendance non versionnée ou modifiée sans préavis reçoit un risque plus élevé.
Le graphe identifie les points uniques de défaillance et les dépendances partagées entre plusieurs parcours. Il montre aussi les boucles où deux systèmes se renvoient des mises à jour et peuvent créer une répétition infinie ou écraser une donnée plus récente.
Deux signaux faibles justifient une priorité élevée : les équipes ne savent pas nommer tous les consommateurs d’un contrat et un incident exige systématiquement une correction en base. Ils révèlent une dépendance invisible et une capacité de reprise insuffisante.
Auditer modèles et qualité des données
La source de vérité est attribuée pour chaque champ critique. Les transformations, valeurs par défaut, unités, fuseaux, devises et règles de conflit sont versionnés.
L’audit compare un échantillon de bout en bout et recherche pertes, troncatures, doublons, valeurs impossibles et divergences entre systèmes. Les statistiques globales sont complétées par des cas entièrement reconstitués qui détectent les compensations invisibles.
Les données sensibles sont minimisées et leur conservation reste justifiée par un besoin explicite. Les journaux et quarantaines ne doivent pas devenir des copies incontrôlées de charges utiles contenant des informations personnelles.
Vérifier identité, secrets et exposition
La scorecard examine authentification, autorisation, portée des tokens, rotation, stockage des secrets, chiffrement et séparation des environnements. Un secret de test ne doit jamais donner accès à la production.
Les webhooks vérifient leur authenticité, leur fraîcheur et la protection contre les rejeux. Les points d’accès exposés limitent taille, débit et formats avant traitement. Les erreurs ne révèlent ni secret ni détail interne inutile.
Les droits suivent le moindre privilège, les changements de fonction et les départs. Une capacité d’administration ou d’export massif doit être tracée et soumise à un contrôle proportionné.
Tester idempotence, erreurs et reprises
Chaque opération à effet de bord possède une clé d’idempotence. Le test envoie doublons, événements tardifs et réponses perdues pour vérifier que l’état final reste correct.
Les erreurs sont classées : entrée invalide, conflit métier, limite, indisponibilité temporaire et défaut permanent. La relance automatique s’applique seulement aux erreurs compatibles, avec backoff et plafond.
La quarantaine conserve le contexte, la cause, la version et l’action réellement attendue. La reprise est autorisée, tracée et rapprochée jusqu’au système destinataire. Une correction directe en base sans journal diminue fortement la note, même si elle dépanne vite.
Le coût caché de la reprise manuelle ne se limite pas au temps d’exécution : il inclut l’enquête, la validation, le risque de doublon et le rapprochement final. L’audit annualise ce coût par motif afin de comparer honnêtement correction durable et traitement récurrent.
Mesurer latence, quotas et capacité
La latence est mesurée de l’événement métier au résultat, pas uniquement sur l’appel HTTP. Les percentiles révèlent les traitements lents que la moyenne masque.
Les quotas sont convertis en capacité nominale, pic et rattrapage. L’intégration sait ralentir, prioriser et reprendre sans perdre les tâches les plus importantes.
Un test de charge réaliste inclut taille des payloads, pagination, appels aval et stockage. Le mode dégradé indique quelles fonctions continuent et quelles données deviennent trop anciennes.
Évaluer observabilité et preuve
Une corrélation relie événement, appels, transformations, file et résultat métier. Les tableaux suivent débit, erreur, ancienneté, retard, coût et population touchée.
Les alertes possèdent un seuil, une fenêtre, un responsable et une procédure de résolution testée. Elles se déclenchent avant la conséquence lorsque c’est possible, par exemple sur une file qui vieillit avant le dépassement du délai de service.
La preuve de succès est positive : commande présente, document signé, compte activé. Un statut 200 ne suffit pas si la réponse n’a pas été appliquée par le système consommateur.
Auditer exploitation et incidents
L’équipe exécute une procédure de diagnostic avec une personne non spécialiste. Elle doit trouver la population, contenir l’effet, décider une relance et confirmer le retour à la normale.
L’historique des incidents montre fréquence, temps de détection, temps de restauration et récidives. Les actions post-mortem sont vérifiées dans le système, pas seulement déclarées closes.
Les déploiements, migrations de schéma et changements de configuration ont une recette et un scénario de retour arrière. Une intégration rarement modifiée peut être risquée précisément parce que personne n’a rejoué sa procédure depuis longtemps.
Qualifier fournisseurs et réversibilité
Contrats, SLA, support, roadmap, versions et fin de vie sont rapprochés du besoin. La disponibilité annoncée est comparée aux incidents observés et aux plages critiques.
L’audit vérifie l’export des données, le remplacement des secrets, la documentation des correspondances et la capacité à brancher une alternative. La réversibilité est chiffrée par scénario, pas simplement mentionnée dans une clause contractuelle.
Un fournisseur central sans solution de repli peut être acceptable si le risque est explicite, couvert par un mode dégradé et accepté par le sponsor. Le masquer derrière une abstraction technique ne réduit ni sa probabilité ni sa conséquence.
Calculer le coût complet
Le coût additionne licence, appels, infrastructure, stockage, supervision, maintenance, support et opérations manuelles. Les incidents et les reprises sont valorisés avec leur fréquence, leur durée et les équipes réellement mobilisées.
Le coût par transaction saine ou par décision utile permet de comparer des intégrations différentes. Une solution moins chère en abonnement peut coûter davantage si elle demande des contrôles quotidiens.
Les scénarios de croissance et de panne testent la sensibilité aux volumes, quotas et prix variables. Le coût de sortie est ajouté à la décision de trajectoire.
Noter avec veto et preuves
Chaque axe reçoit une note, un niveau de confiance et des preuves. Les pondérations reflètent la criticité : sécurité et idempotence pèsent davantage pour un paiement que pour un enrichissement non bloquant.
Les veto couvrent les risques inacceptables : secret exposé, absence de sauvegarde d’un état critique, doublon financier possible ou impossibilité de respecter une obligation. Ces risques ne sont jamais compensés par une bonne moyenne sur des axes secondaires.
Le plan ordonne réduction de risque, valeur, effort et dépendances entre les actions retenues. Chaque action possède un test de fermeture mesurable et un responsable. La scorecard est rejouée après la vague pour démontrer le progrès.
La priorité traite d’abord les veto et les risques au rayon d’impact élevé, puis les causes répétitives coûteuses. Les améliorations de confort arrivent seulement lorsque l’intégration peut être restaurée, expliquée et rapprochée sans dépendre d’une personne précise.
Conclusion : décider la trajectoire
L’audit d’intégration API relie code, données et exploitation à une conséquence métier. Il révèle les systèmes qui fonctionnent grâce aux contournements autant que ceux qui échouent visiblement.
Les tests d’erreur et de reprise donnent une preuve plus forte qu’une revue nominale. Les veto protègent contre les risques qui ne doivent jamais être moyennés.
Le résultat attendu est une trajectoire : conserver, sécuriser, découpler, moderniser ou remplacer, avec un coût, des responsables et des critères de sortie.
Dawap conduit ces diagnostics dans ses missions d’intégration API, puis réalise les remédiations jusqu’aux preuves de run et de réversibilité.
