Intégrer un système sans documentation technique publique
Certains partenaires n'exposent aucune documentation technique exploitable, sans pour autant rendre l'intégration impossible : c'est un type de mission que je traite par analyse du trafic réseau.
Le besoin type
Une plateforme de livraison, une caisse propriétaire, un outil métier fermé : certains systèmes que l'on souhaite connecter à une boutique n'exposent aucune API officielle ni documentation technique. Leur seule interface disponible est une application web ou desktop destinée à un usage humain. Le besoin reste pourtant le même que pour une intégration classique — synchroniser des prix, des menus, des commandes ou des stocks — mais sans le point de départ habituel qu'est une documentation d'API.
Comment j'interviens sur ce genre de besoin
La méthode consiste à observer les échanges réseau générés par l'interface officielle du système pendant un usage normal : quelles requêtes partent, avec quels paramètres, dans quel ordre, avec quelle authentification. Cette analyse permet de reconstruire progressivement le comportement de l'API sous-jacente, même sans qu'elle soit documentée nulle part. Ce travail demande de la rigueur : reproduire les mêmes en-têtes, respecter le même format de données, et ne pas se contenter d'une requête qui fonctionne une fois pour la considérer comme fiable.
Une fois le comportement compris, je construis l'intégration comme pour une API classique, avec un point supplémentaire : une surveillance renforcée dans le temps. Un système qui n'a jamais promis de stabilité peut changer sans préavis, contrairement à une API versionnée volontairement. La couche d'intégration doit être conçue pour détecter rapidement une rupture, avec une dégradation contrôlée plutôt qu'un échec silencieux qui passerait inaperçu pendant plusieurs jours.
Facteurs qui influencent le chiffrage
-
Complexité de l'authentification
Un simple jeton d'accès se reproduit facilement ; un mécanisme de sécurité plus élaboré, avec renouvellement automatique, demande davantage de travail d'analyse.
-
Stabilité observée du système
Un système peu modifié dans le temps réduit le risque de rupture ultérieure par rapport à un système mis à jour fréquemment.
-
Richesse des échanges nécessaires
Lire une seule donnée (un prix, une disponibilité) est plus simple qu'un échange bidirectionnel complet incluant la création de commandes.
-
Criticité de la donnée synchronisée
Une donnée affichée publiquement en quasi temps réel impose une surveillance plus stricte qu'une donnée mise à jour une fois par jour à titre informatif.
Questions fréquentes
Cette approche est-elle légale ?
Ce type d'intégration est-il aussi fiable qu'une API officielle documentée ?
Combien de temps faut-il pour reconstruire une intégration de ce type ?
Que faire si le système change effectivement après la mise en production ?
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.