Préparer une panne ou un changement d’API externe
Une API externe est une dépendance : sa documentation accessible ne garantit pas que votre application puisse l’utiliser. Préparez le fonctionnement attendu lorsque la réponse manque, arrive trop tard ou change de structure.
Nommer la dépendance et ses effets
Listez les fonctions utilisant l’API, les données reçues, les autorisations et la personne chargée du suivi. Distinguez un catalogue décrivant un service et un accès opérationnel effectivement obtenu.
La fiche officielle de l’API Offres d’emploi publie actuellement un avis d’interruption de son exposition sur pole-emploi.io. Ce constat montre pourquoi une URL documentaire ne suffit pas à valider une intégration ; il ne préjuge pas d’une fermeture définitive.
Définir un délai et un résultat de repli
Fixez un délai compatible avec la tâche de l’utilisateur. À son expiration, affichez un état compréhensible : donnée indisponible, ancien résultat daté ou traitement différé. Ne remplacez pas une absence par une valeur plausible.
Exemple fictif : une page comparant des indicateurs peut rester lisible si elle signale la date du dernier résultat. Elle ne doit pas afficher « aucune offre » quand le service de recherche ne répond pas.
Simuler les erreurs dans un environnement isolé
Préparez des réponses fictives : succès, réponse vide, erreur d’autorisation, délai dépassé et champ manquant. Comparez l’affichage et les journaux au résultat prévu, sans multiplier les appels au service réel.
Pour une action qui écrit chez un tiers, simulez aussi une réponse perdue après exécution. La reprise doit vérifier ce qui s’est réellement passé avant de réessayer, sinon une opération peut être effectuée deux fois.
Distinguer fraîcheur et disponibilité
Si des résultats sont conservés, définissez ce qui peut être montré, pendant combien de temps et avec quelle date. Une valeur ancienne peut être utile pour un historique et trompeuse pour une situation immédiate.
Documentez les données non conservables ou trop sensibles et les autorisations de réutilisation. Un cache n’autorise pas automatiquement une conservation illimitée ou une republication.
Organiser la reprise et la surveillance
Préparez un signalement proportionné, un responsable et une tâche de vérification après rétablissement. Contrôlez les changements de schéma et les enregistrements restés en attente avant de déclarer le service revenu.
Gardez une procédure manuelle pour les fonctions essentielles. La surveillance doit suivre l’utilité réelle du parcours : une réponse HTTP correcte peut encore contenir une information inexploitable.
Une fiche à conserver avec la décision
| Élément | Preuve |
|---|---|
| Dépendance | Service, fonction, accès et responsable. |
| Repli | Délai, message et données utilisables. |
| Essais | Cas fictifs et résultats attendus. |
| Reprise | Contrôle des tâches en attente et preuve de retour. |
Télécharger la fiche à compléter (CSV)
Questions fréquentes
Un HTTP 200 prouve-t-il que l’intégration fonctionne ?
Non. Vérifiez contenu, schéma, autorisation et résultat métier.
Faut-il réessayer automatiquement toute erreur ?
Pas sans connaître le type d’action et les effets d’un doublon. Les opérations d’écriture demandent un contrôle particulier.
Références
France Travail · Avis de distribution de l’API Offres d’emploi
La grille pratique est une synthèse éditoriale à adapter à votre service. Elle ne constitue ni une certification ni un résultat d’audit.