---
title: "Répondre à une question d’intégration malgré les inconnues"
description: "Construisez une réponse vérifiable à partir des échanges métier, preuves disponibles, comportements en panne, responsabilités, tests et changements."
canonical: "https://zephior.com/fr/insights/answer-an-rfp-integration-question"
last-updated: 2026-09-04
---

# Répondre à une question d’intégration malgré les inconnues

> Construisez une réponse vérifiable à partir des échanges métier, preuves disponibles, comportements en panne, responsabilités, tests et changements.

Par [Tony Kim](https://zephior.com/fr/authors/tony-kim). Publié le 2026-09-04; mis à jour le 2026-09-04. 19 min de lecture.

## Définition

Une réponse d’intégration explique les échanges nécessaires entre la solution proposée et les systèmes extérieurs, puis la manière de les spécifier, construire, protéger, tester, exploiter et faire évoluer. Elle part des événements métier et de leurs résultats observables. Pour chaque échange important, elle distingue les données certaines du dossier, le choix proposé par le candidat, l’hypothèse à confirmer et l’inconnue. Elle décrit aussi les erreurs, les reprises, le rapprochement et la recette. Elle ne présente jamais comme compatible une interface qui n’a pas été documentée ou testée.

## Problème

Le cahier des charges demande une connexion avec le portail usager, le système d’information géographique, les véhicules de collecte et le progiciel financier. Certains flux sont dits temps réel, sans événement précis ni délai mesurable. Les candidats promettent alors une plateforme ouverte et des API sécurisées. L’acheteur ignore toujours quel système fait foi pour une adresse, ce qui arrive à un signalement lorsque la télématique est indisponible, comment une facture rejetée est rapprochée ou qui maintient le connecteur après la mise en service. La réponse donne une orientation technique sans rendre la prestation évaluable.

## Point de vue

Répondez par un contrat de comportement avant de répondre par un catalogue de technologies. L’intégration commence par une action métier, une autorité sur la donnée et un état attendu. Le protocole vient ensuite. Toute promesse doit porter son statut de preuve, sa frontière de responsabilité, son scénario d’échec et sa vérification. Une norme ouverte facilite la description et la réutilisation; elle ne prouve ni le sens des données ni la compatibilité de deux installations. Lorsque l’acheteur ne peut pas encore fournir un détail, proposez une hypothèse bornée, une étape de validation et une solution de repli gouvernée.

## La première frontière sépare le dossier de ce que le candidat imagine

Reprenez la question avec le règlement de consultation, la grille de notation, les cahiers des charges, annexes de données, schémas, réponses aux candidats, niveaux de service, cadre de prix et projet de marché. Notez ce qui est demandé: expliquer une méthode, garantir une compatibilité existante, concevoir une cible, fournir une preuve ou prendre un engagement d’exploitation. Le Code de la commande publique français permet, dans le cadre de l’article R2152-7, que des critères portent notamment sur l’interopérabilité et les caractéristiques opérationnelles. Seules les règles publiées du marché concerné déterminent toutefois la réponse attendue.

Attribuez un statut à chaque phrase technique. Confirmée signifie que la pièce applicable le dit. Observée signifie qu’une vérification autorisée, datée et bornée l’a montré. Proposée signifie que le candidat maîtrise ce choix. Supposée signifie que conception, délai ou prix dépendent encore d’une confirmation. Inconnue signifie qu’aucune valeur défendable n’existe. Un connecteur déjà réalisé pour un autre client ne transforme pas la version locale d’un progiciel en interface connue.

La Métropole des Trois Rivières, cas entièrement fictif, renouvelle son service de gestion des déchets. Elle demande des échanges avec un portail citoyen, un SIG, une télématique de flotte et le progiciel financier. Le dossier contient un dictionnaire d’adresses et une description du flux financier, mais aucune documentation de la télématique. L’offre s’engage donc sur les résultats métier, les contrôles communs et la preuve à fournir. Elle présente deux options bornées pour la télématique au lieu d’inventer son API.

**Base de réponse pour Trois Rivières**

| Échange | Preuve disponible | Engagement défendable | Validation restante |
| --- | --- | --- | --- |
| Adresse et secteur de collecte | Dictionnaire et règles SIG | Valider contre la version publiée et conserver la référence | Test sur adresses limites |
| Signalement usager | Parcours et délai attendus | Créer un signalement unique avec accusé distinct de la résolution | Contrat du portail |
| Passage du véhicule | Résultat métier, interface absente | Proposer événement ou dépôt planifié selon capacités constatées | Accès à la télématique |
| Écriture de facturation | Flux nocturne décrit | Fichier contrôlé, totalisé et rapproché avec rejets nommés | Format final et environnement |

## Une intégration se décrit par événements, pas par logos

Décomposez chaque connexion en échanges. Le portail peut demander le secteur d’une adresse, créer un signalement, consulter son état et recevoir une clôture. Ce sont quatre contrats différents, même s’ils utilisent le même endpoint. Donnez à chacun un identifiant stable, un déclencheur, une source, une destination, un objet de référence, une autorité, un délai utile, un résultat attendu et une conséquence si ce résultat n’arrive pas.

Distinguez les étapes. Un message reçu n’est pas forcément valide; un message valide n’est pas forcément accepté par le métier; une acceptation ne signifie pas que la collecte a eu lieu. L’accusé doit indiquer l’étape qu’il confirme. Pour un signalement, l’usager peut recevoir immédiatement une référence alors que la planification intervient plus tard. Si le système de tournée refuse l’adresse, cette référence doit conduire à un état explicable, pas à une disparition silencieuse.

Choisissez l’interaction d’après ce délai. La recherche de secteur peut justifier une requête immédiate si le portail peut tolérer la disponibilité du SIG ou utiliser une copie autorisée. Un événement de passage peut arriver après la tournée. Un export financier planifié facilite les totaux de contrôle. Le fichier n’est pas archaïque par nature et l’API n’est pas moderne par nature. Le bon choix permet le résultat, la reprise et la preuve exigés.

- Une connexion technique peut porter plusieurs contrats métier.
- Chaque état possède une autorité et une définition datée.
- Réception, validation, acceptation et réalisation restent séparées.
- Le délai utile décide si l’appelant peut attendre.
- Le mode dégradé appartient au service rendu, pas seulement à l’infrastructure.

## Le format devient utile lorsque le sens et les erreurs sont versionnés

Pour chaque objet, définissez noms, sens, identifiants, unités, fuseaux, codes, valeurs obligatoires, absence, relations, exemples et cycle de vie. Dans Trois Rivières, «collecté» peut signifier capteur déclenché, confirmation du chauffeur ou tournée validée. Le candidat ne choisit pas discrètement cette définition. Il consigne le sens proposé ou fourni, la personne qui l’approuve et l’effet sur réclamation, reporting et facturation.

OpenAPI permet de décrire une interface HTTP, AsyncAPI des échanges orientés messages et JSON Schema des contraintes de données. CloudEvents peut donner une enveloppe commune aux événements. Ces spécifications rendent des éléments inspectables par des humains et des outils; elles ne fixent pas seules le vocabulaire déchets, la livraison, l’ordre ou la rétention. Indiquez version, profil, exemples, code d’erreur et extensions retenus. Conservez la spécification acceptée comme baseline.

Ajoutez ensuite identité, autorisation et transport au niveau approprié à l’offre. Précisez propriétaire de l’endpoint, classe d’authentification, périmètre minimal, chiffrement, réseau et limites sans révéler identifiants, adresses privées ni configuration défensive. RFC 9700 formule des pratiques de sécurité OAuth dans son champ. Il ne suffit pas à prouver que le schéma d’habilitation de l’acheteur convient. Cette conclusion appartient à l’analyse de sécurité compétente.

**Contenu minimal d’un contrat d’échange**

| Plan | Questions à trancher | Artefact | Limite du constat |
| --- | --- | --- | --- |
| Métier | Événement, autorité, résultat et délai | Fiche d’échange | Ne prouve pas le transport |
| Sémantique | Champs, codes, identifiants et états | Schéma et exemples versionnés | Ne prouve pas la justesse des sources |
| Interaction | Appel, message, événement ou fichier | Description du protocole | Ne prouve pas le fonctionnement réel |
| Confiance | Identité, droit, protection et réseau | Profil de sécurité approuvé | Ne remplace pas l’homologation |
| Exploitation | Limites, surveillance, panne et support | Profil de service | Ne garantit pas un tiers futur |

## Un timeout ne dit pas si le signalement existe déjà

Recensez validation refusée, identité non autorisée, dépendance indisponible, timeout, quota, traitement partiel, doublon, ordre incorrect, message expiré, version inconnue et référence métier absente. Définissez pour chacun réponse observable, effet métier, conservation, alerte, correction et décision. RFC 9457 normalise une structure de détails de problème pour des API HTTP. Le type d’erreur doit aider le consommateur sans exposer les entrailles de l’implémentation.

Ne relancez automatiquement qu’une opération dont l’échec paraît transitoire et dont la répétition est sûre. Fixez nombre, délai progressif, durée totale et arrêt. Une clé métier stable ou clé d’idempotence peut permettre au destinataire de reconnaître la même demande et de rendre le résultat existant. Si cette propriété n’est pas confirmée, interrogez l’issue précédente ou rapprochez les systèmes avant de créer une seconde action. Les recommandations Microsoft, AWS et Google fournissent des principes techniques dans leurs environnements; le contrat métier reste propre au service.

Le rapprochement compare envoyés, reçus, acceptés, rejetés et terminés sur une même période avec une corrélation partagée. Le flux financier compare lignes, montants, taxes si applicables, fichier rejeté et référence de comptabilisation. Le flux de passages compare événements, tournées, bacs et signalements associés. Les journaux doivent prouver l’écart tout en respectant les règles de protection. Un total égal ne justifie pas une ligne manquante compensée par une autre.

**Décision après incident d’échange**

| Observation | Action sûre | Preuve attendue | Pouvoir requis |
| --- | --- | --- | --- |
| Timeout après création | Rechercher la référence avant toute relance | Demande initiale et résultat retrouvé | Runbook approuvé |
| Message dupliqué | Conserver une seule conséquence métier | Identifiant et décision de doublon | Propriétaire de l’objet |
| Schéma refusé | Aucune modification partielle non déclarée | Erreur liée à la version | Responsable du contrat |
| Télématique hors ligne | Mettre en attente avec âge visible | Backlog et dernière donnée reçue | Responsable de service |
| Écart inexpliqué | Suspendre la recette du flux | Rapprochement des deux côtés | Autorité de recette |

## Attribuer le connecteur ne suffit pas à exploiter l’échange

Distribuez spécification, endpoint, adaptateur, transformation, route réseau, identités, certificats, environnements, données d’essai, supervision, traitement d’alerte, diagnostic, rejeu, correction fonctionnelle, support et changement. Nommez le livrable et la décision. La métropole peut posséder le référentiel d’adresses, l’éditeur de flotte l’endpoint et le titulaire la transformation. La recette doit toutefois conclure sur un résultat partagé.

Transformez chaque contribution extérieure en prérequis daté. «Accès fourni par l’acheteur» devient un environnement, un rôle, une portée, une donnée représentative, une preuve de connectivité, une date et une activité dépendante. Montrez ce qui continue si l’accès tarde et quand le chemin critique change. N’inventez pas un droit à prolongation ou rémunération. Alignez le traitement sur le marché et faites accepter le risque résiduel par l’autorité commerciale.

Organisez la visibilité commune. W3C Trace Context peut relier des traces techniques si chaque partie le met en œuvre et l’autorise. Une corrélation métier reste nécessaire pour le support et le rapprochement. Précisez qui voit latence, file, âge, rejet et état final, comment un ticket traverse la frontière, quelles preuves peuvent être partagées et qui décide un rejeu. Ne promettez pas les journaux d’un tiers.

- Relier tout prérequis à un jalon et à une preuve utilisable.
- Séparer surveillance technique, diagnostic et correction métier.
- Nommer l’autorité qui peut rejouer, bloquer ou accepter un écart.
- Inclure le délai de l’éditeur tiers dans le calendrier engagé.
- Définir un support fondé sur des identifiants que les deux parties retrouvent.

## Chaque environnement limite la conclusion que le test autorise

Construisez une chaîne. La revue de spécification vérifie opérations, messages, champs, exemples et erreurs. Les tests de schéma et de contrat exercent la frontière. Le test de composant couvre la réalisation du candidat. Le parcours de bout en bout inclut réseau, identité, extrémités et état métier. Les tests négatifs, de charge et de mode dégradé observent rejet, limites, attente, reprise et rapprochement. Chaque étage répond à une question différente.

Une fiche de test porte exigence, environnement, version de contrat, entrées maîtrisées, résultat observable, seuil, preuve, propriétaire de l’anomalie et autorité de recette. Un bac à sable ne prouve pas la route de production. Un mock ne prouve pas le comportement du progiciel. Des données synthétiques ne prouvent pas la distribution réelle. Utilisez chaque support pour ce qu’il montre et annoncez le contrôle supplémentaire qui ferme la limite.

Pour Trois Rivières, un même signalement est présenté deux fois après un timeout simulé. Le résultat attendu est une référence unique et un état récupérable. Un événement de passage est envoyé hors ordre et ne doit pas faire revenir une tournée clôturée à un état antérieur. Une indisponibilité télématique crée un backlog visible qui est rejoué puis rapproché. Un code financier invalide produit une ligne de rejet identifiée sans perdre les autres totaux.

**Chaîne de preuve d’un signalement**

| Niveau | Conclusion permise | Conclusion non permise seule | Preuve de sortie |
| --- | --- | --- | --- |
| Revue du contrat | États, messages et erreurs sont définis | Compatibilité en exécution | Baseline approuvée |
| Test de contrat | Exemples et réactions suivent la version | Route et identité de production | Résultat automatisé versionné |
| Parcours complet | Les systèmes de test atteignent le bon état | Charge et différences de production | Références des deux systèmes |
| Mode dégradé | La panne nommée est contenue et récupérée | Tous les incidents possibles | Chronologie, backlog et rapprochement |
| Aptitude au service | Supervision et support sont opérationnels | Absence de changement futur | Décision de mise en service |

## Ajouter un champ peut encore casser le comportement

Figez ensemble description d’interface, schémas, exemples, listes de codes, profil d’identité, limites et consignes d’exploitation utilisés pour la recette. Une évolution additive n’est pas toujours compatible. Un nouvel état peut être rejeté ou ignoré; une nouvelle valeur par défaut peut changer une décision; un droit plus étroit peut arrêter un traitement. Évaluez compatibilité du code, des données échangées et du comportement des consommateurs existants.

Définissez proposition, étude d’impact, autorisation, préavis, tests, coexistence, retrait, retour et mise à jour documentaire. N’annoncez pas une durée de préavis que l’acheteur ou l’éditeur n’a pas acceptée. Si l’interface extérieure change, la réponse doit montrer l’hypothèse commerciale retenue et la voie prévue par le marché pour décider les effets. Une norme ou une obligation d’interopérabilité n’établit pas que toute évolution est sans coût.

Le Règlement général d’interopérabilité français organise des recommandations de standards dans son périmètre, tandis que le règlement européen 2024/903 traite plusieurs dimensions de l’interopérabilité pour le secteur public européen. Ces textes peuvent éclairer la conception selon le contexte applicable. Ils ne choisissent ni le profil de télématique de Trois Rivières ni la preuve de recette. L’offre doit toujours revenir aux exigences et versions du marché.

## L’absence de documentation appelle une décision, pas une promesse vague

Avant la date limite, utilisez le canal de questions lorsqu’un élément absent modifie conformité, architecture obligatoire, prix significatif, calendrier ou comparabilité. Citez la pièce et demandez le paramètre minimal qui change l’offre: version, mode d’échange, responsabilité, plage de volume ou date d’environnement. La clarification des dépendances techniques délimite l’offre. La présente réponse intègre ensuite la réponse reçue ou conserve une hypothèse visible.

Si la validation ne peut intervenir qu’après attribution, nommez la décision, les intrants, les parties, le jalon, l’option proposée, le critère de succès et la suite si l’hypothèse échoue. Exemple fictif: le candidat suppose que la télématique peut restituer un identifiant stable de passage et les événements de la fenêtre convenue. Après accès autorisé, il vérifie échantillon, ordre, doublon et reprise. Si la capacité manque, l’export planifié est évalué selon la voie de changement du marché. Les vrais délais et effets doivent provenir du contrat, pas de cet exemple.

La réponse finale peut alors rester lisible. Pour chaque échange, présentez finalité, preuve disponible, comportement offert, responsabilités, panne, vérification, recette et confirmation ouverte. Mutualisez seulement la gouvernance réellement commune. Ne dupliquez pas les conclusions de sécurité, protection des données, migration ou continuité. Les spécialistes intégration définissent le comportement technique; les autorités métier, sécurité, juridique, données et commerce approuvent leurs propres engagements.

## Résultats utiles

- Chaque interface est décomposée en échanges métier identifiables et mesurables.
- Les faits du dossier, propositions, hypothèses, dépendances et inconnues ne se mélangent pas.
- Le sens des objets et états précède le choix du protocole ou du produit.
- Accusé technique, acceptation fonctionnelle et résultat final sont différenciés.
- Panne, répétition, ordre, retard, rejet et rapprochement ont un traitement explicite.
- Construction, accès, supervision, incident, correction et évolution ont chacun un responsable.
- La preuve progresse du contrat de données au parcours complet et au mode dégradé.
- La recette repose sur une version, un environnement, des seuils et une autorité nommés.

## Déroulement

1. **Identifier la promesse évaluée.** Rassemblez question, critères, spécifications, schémas, annexes, réponses acheteur, prix et contrat afin de distinguer approche, conception, preuve existante et engagement.
2. **Qualifier chaque information.** Associez à toute caractéristique d’interface une source, une version, une date et un statut: confirmée, observée, proposée, supposée ou inconnue.
3. **Découper les échanges métier.** Attribuez un identifiant à chaque déclencheur, objet, source, destination, état attendu, délai utile et conséquence d’un échec.
4. **Écrire le comportement de frontière.** Définissez sémantique, schéma, version, identité, interaction, validation, accusé, erreur, ordre, répétition, limite et rapprochement.
5. **Distribuer les obligations.** Affectez spécification, endpoints, adaptateurs, réseau, identités, environnements, données de test, supervision, incidents, corrections, support et changement.
6. **Construire la chaîne de preuve.** Reliez chaque exigence à des revues, tests de contrat, composants, parcours de bout en bout, erreurs, charge et reprise avec résultat et preuve attendus.
7. **Traiter ce qui reste ouvert.** Posez la question de clarification qui change l’offre ou consignez une hypothèse autorisée avec étape, options, critère et conséquence de validation.
8. **Faire approuver une réponse cohérente.** Réconciliez les engagements avec sécurité, données, migration, continuité, exploitation, planning, prix et contrat avant la validation finale.

## Décisions clés

- Quels échanges sont indispensables au service demandé et lesquels relèvent d’une option?
- Quelle pièce applicable fonde chaque affirmation concernant le système d’un tiers?
- Qui fait autorité pour l’adresse, le secteur de collecte, le passage, la réclamation et la créance?
- Quel résultat doit être immédiat et quel traitement peut être différé sans nuire au service?
- Quels schéma, profil, version, identité et limites peuvent être engagés avant accès?
- Quel comportement protège le métier après un timeout, un doublon, un retard ou un traitement partiel?
- Qui fournit et exploite chaque extrémité, transformation, accès, alerte et correction?
- Quels environnements et jeux représentatifs existent pour chaque niveau de preuve?
- Quelles observations suffisent à la recette technique puis fonctionnelle?
- Quelle évolution reste compatible et laquelle exige décision, transition et nouvelle preuve?

## Risques

- Un schéma dessiné par le candidat peut être confondu avec l’architecture confirmée de l’acheteur.
- Deux systèmes peuvent partager JSON tout en donnant des sens opposés au même statut.
- La répétition automatique peut créer deux signalements, deux tournées ou deux écritures comptables.
- Une chaîne synchrone peut rendre le portail indisponible au moindre arrêt d’un tiers.
- Une file peut conserver les messages sans respecter le délai utile d’une réclamation.
- Un simulateur peut ignorer les certificats, quotas et comportements du produit réel.
- Un petit jeu d’essai peut masquer pics saisonniers, adresses atypiques et pièces volumineuses.
- L’incident peut rester sans pilote entre collectivité, titulaire et éditeur de télématique.
- Une évolution de l’interface peut créer une obligation non chiffrée après la recette.
- La réponse peut engager sécurité, protection des données ou droit métier sans validation compétente.

## Indicateurs

- échanges matériels avec identifiant, événement, autorité et résultat attendu
- affirmations techniques rattachées à une source applicable et datée
- éléments de contrat marqués confirmés, proposés, supposés ou inconnus
- modes d’échec dotés d’un comportement sûr, d’un responsable et d’un rapprochement
- prérequis acheteur ou tiers avec date et preuve de mise à disposition
- tests de schéma et de contrat réussis sur la version retenue
- parcours de bout en bout réussis avec des conditions représentatives
- reprise respectant les seuils de perte, retard, doublon et backlog
- conditions de recette réussies, dérogées par autorité ou encore explicitement ouvertes

## Questions fréquentes

### Peut-on répondre sans connaître l’API du système acheteur?

Oui, en séparant le résultat métier requis du contrat technique encore inconnu. Proposez un comportement borné, des responsabilités, une étape de validation, des critères de recette et une option de repli. Ne prétendez pas avoir testé l’interface.

### Une API est-elle toujours préférable à un fichier?

Non. Le choix dépend du délai utile, du volume, de la disponibilité, de la preuve et de la reprise. Un fichier contrôlé peut convenir à un rapprochement planifié; un appel immédiat peut convenir à une décision interactive.

### OpenAPI garantit-il l’interopérabilité?

Non. Il décrit une interface HTTP. Le sens des données, les versions, l’identité, le réseau, les limites, les erreurs, la mise en œuvre et les tests de bout en bout restent à établir.

### Quelle est l’unité utile d’une réponse d’intégration?

Un échange métier identifié avec déclencheur, source, destination, objet faisant autorité, résultat, comportement, responsabilités, panne, vérification et recette.

### Quand peut-on relancer automatiquement?

Quand l’erreur est probablement transitoire, que les relances sont limitées et que la même action ne produit pas une seconde conséquence métier. Sinon, il faut d’abord rechercher ou rapprocher le résultat précédent.

### Un test en bac à sable suffit-il à la recette?

Il prouve uniquement les conditions représentées par ce bac. Routage, identités, quotas, données, charge, tiers, exploitation et pannes de production peuvent nécessiter des preuves supplémentaires.

### Qui possède une interface partagée?

La propriété doit être répartie par élément. Contrat, endpoints, adaptateurs, identités, supervision, incidents, correction, recette et évolution ont chacun une partie responsable et une autorité de décision.

### Comment conclure la réponse quand des détails restent inconnus?

Présentez pour chaque échange le résultat, le statut de preuve, le comportement offert, les responsabilités, le traitement des pannes, la preuve, la recette et l’hypothèse bornée qui reste à confirmer.


## Sources primaires

- [OpenAPI Specification 3.2.0](https://spec.openapis.org/oas/latest.html), OpenAPI Initiative
- [AsyncAPI Specification 3.0.0](https://www.asyncapi.com/docs/reference/specification/v3.0.0), AsyncAPI Initiative
- [Spécification JSON Schema](https://json-schema.org/specification), JSON Schema
- [RFC 9110, HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110.html), RFC Editor
- [RFC 9457, Problem Details for HTTP APIs](https://www.rfc-editor.org/rfc/rfc9457.html), RFC Editor
- [RFC 9700, pratiques de sécurité OAuth 2.0](https://www.rfc-editor.org/rfc/rfc9700.html), RFC Editor
- [W3C Trace Context Recommendation](https://www.w3.org/TR/trace-context/), World Wide Web Consortium
- [Spécification et ressources CloudEvents](https://cloudevents.io/), Cloud Native Computing Foundation
- [AIP-180: Backwards Compatibility](https://google.aip.dev/180), Google API Improvement Proposals
- [AIP-194: Automatic Retry Configuration](https://google.aip.dev/194), Google API Improvement Proposals
- [Microsoft Azure Retry Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/retry), Microsoft Azure Architecture Center
- [AWS Retry with Backoff Pattern](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html), Amazon Web Services
- [Code de la commande publique, article R2152-7](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000037730485), Légifrance
- [Référentiel général d’interopérabilité, version 2.0](https://www.numerique.gouv.fr/uploads/Referentiel_General_Interoperabilite_V2.pdf), Direction interministérielle du numérique
- [API Entreprise, documentation pour les développeurs](https://production.entreprise.api.gouv.fr/developpeurs), Direction interministérielle du numérique
- [API Entreprise, spécifications et disponibilité](https://production4.entreprise.api.gouv.fr/), Direction interministérielle du numérique
- [API Particulier, documentation développeur](https://production.particulier.api.gouv.fr/developpeurs), Direction interministérielle du numérique
- [Trackdéchets, bonnes pratiques d’utilisation de l’API](https://developers.trackdechets.beta.gouv.fr/guides/good-practices), Ministère de la Transition écologique
- [Recommandations relatives à l’administration sécurisée des systèmes d’information](https://messervices.cyber.gouv.fr/guides/recommandations-relatives-ladministration-securisee-des-si), Agence nationale de la sécurité des systèmes d’information
- [Règlement (UE) 2024/903 pour une Europe interopérable](https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32024R0903), EUR-Lex


## Articles complémentaires

- [Clarifier les interfaces et dépendances de l’acheteur](https://zephior.com/fr/insights/clarify-technical-interface-dependencies)
- [Répondre à une question de migration sans masquer les inconnues](https://zephior.com/fr/insights/answer-an-rfp-data-migration-question)
- [Répondre à une question RFP sur la mise en oeuvre](https://zephior.com/fr/insights/answer-an-rfp-implementation-approach-question)
- [Répondre à une question de scalabilité avec des mesures](https://zephior.com/fr/insights/answer-an-rfp-scalability-question)