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

Base de réponse

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.

Échanges métier

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.

Contrat de frontière

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.

Panne et reprise

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.

Responsabilités

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.

Vérification

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.

Évolution

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é.

Inconnues

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.