Le connecteur doit exporter les clients de la société A vers le CRM. Pendant la recette, une lecture menée avec son identité renvoie aussi une fiche de la société B, exclue du projet. Le flux habituel continue de fonctionner et ses journaux affichent bien A. Le périmètre technique de lecture dépasse celui que le métier avait demandé ; le risque de transfert d’une mauvaise fiche subsiste si le routage change.
Le point à vérifier est précis : choisir une société dans la configuration du middleware ne limite pas nécessairement les autorisations de l’application dans Business Central. Une route correcte protège le parcours prévu contre certaines erreurs de sélection ; elle ne démontre pas ce que le même compte pourrait lire ailleurs. La recette doit donc observer le parcours autorisé et les refus attendus.
Nous construisons cette comparaison sur deux sociétés fictives et des fiches de test connues. Vous pourrez distinguer identité, paramétrage des permissions et preuves de lecture, puis préparer une revue avec votre administrateur. Le programme joint classe des observations synthétiques ; il ne découvre aucun droit réel, ne collecte aucun token et ne change aucune permission.
Pour cette intégration API, Dawap examine le contrat du connecteur et les observations du flux. Notre accompagnement Business Central et logiciels métier s’effectue avec votre installateur ERP, qui qualifie les objets, les affectations et les dépendances de l’installation.
Pour qui : une application doit rester dans un périmètre de sociétés défini
Transformer une demande commerciale en cas d’accès testables
« Connecter Business Central au CRM » laisse trop de décisions ouvertes. Pour notre exemple, l’équipe commerciale demande seulement la lecture des clients de A. La société B reste hors périmètre, même si elle appartient au même groupe. Le responsable du flux précise aussi les ressources nécessaires : obtenir les clients ne suppose pas de lire les fournisseurs ou les écritures comptables.
Cette délimitation convient à un export, un portail ou un raccordement exploité sans utilisateur présent. Elle devient particulièrement utile lorsqu’une application ancienne a reçu des permissions pour plusieurs projets successifs. Le premier livrable est une liste de parcours acceptés et exclus, attribuée à un propriétaire métier ; ce n’est pas encore une promesse d’isolation exhaustive de tout l’ERP.
Différer les tests tant que leur cadre n’est pas autorisé
Les lectures de contrôle doivent être approuvées et menées sur des données de recette adaptées. Une société exclue du flux n’est pas une invitation à parcourir ses vrais clients pour voir ce qui répond. Préparer avec l’administrateur une fiche synthétique identifiable et les opérations de vérification admises, puis limiter les traces à ces observations.
Si personne ne sait quelle application le traitement planifié utilise, commencer par cette identification. Une démonstration réussie depuis le poste d’un administrateur ne permet pas d’évaluer le compte du worker. Le diagnostic doit pouvoir relier une observation au service effectivement déployé ; à défaut, le dossier reste une collecte technique à compléter.
Distinguer l’autorisation Entra des permissions Business Central
Un token obtenu ne constitue pas un inventaire des droits métier
L’authentification S2S documentée par Microsoft utilise une identité d’application. L’enregistrement Entra et les permissions accordées dans Business Central interviennent à des niveaux différents. Le nom API.ReadWrite.All ne remplace donc pas la revue des objets et du périmètre effectivement attribués dans l’ERP. Un token valide confirme encore moins la conformité du flux à la demande commerciale.
Qualifier les API consommées avant de reprendre une configuration d’exemple. Les permissions de la famille Automation répondent notamment à des usages d’administration ; elles ne doivent pas être ajoutées par habitude à chaque export. Microsoft précise aussi qu’une application ne peut pas recevoir SUPER. La résolution d’un refus passe par les permissions nécessaires au contrat, avec l’administrateur responsable.
Conserver l’identité du traitement réellement exploité
La fiche de recette distingue tenant Entra, environnement Business Central, identité applicative et révision de configuration du connecteur. Les noms lisibles aident le support, mais les correspondances techniques doivent être établies par des sources autorisées. Renommer une application ne doit pas faire croire qu’un nouveau jeu de droits a été créé ou vérifié.
Un SDK peut employer une autre configuration que le script manuel utilisé pendant l’atelier. Vérifier aussi le traitement programmé, les variables résolues et l’environnement ciblé, sans afficher leurs secrets. Le responsable IAM ou l’administrateur confirme l’identité ; l’intégrateur confirme que son adaptateur l’utilise. Ces deux vérifications ne sont pas remplacées par une étiquette ajoutée après coup dans un journal.
Construire une matrice par société, ressource et opération
La matrice suivante exprime notre contrat fictif. A et B sont des libellés de sociétés, pas des GUID prêts à insérer dans une URL. Chaque ligne doit être traduite en opération réellement qualifiée sur l’installation ; la lecture d’un client ne prouve aucun droit d’écriture sur une commande.
| Parcours | Attente | Preuve à recueillir |
|---|---|---|
| Client témoin de A | Lecture autorisée | Identité et fiche reconnues |
| Client témoin de B | Lecture exclue | Refus d’autorisation expliqué |
| Autre ressource | À qualifier | Nouvelle ligne de recette |
| Création de document | Non testée ici | Contrat d’écriture distinct |
| Autre compte | Hors comparaison | Identité et recette séparées |
Choisir des objets dont l’existence est établie séparément
Un refus attendu sur une fiche inexistante n’apprend presque rien sur les permissions. L’administrateur prépare donc les témoins avec une référence et un marqueur reconnaissables, puis confirme leur existence dans le cadre autorisé. La lecture avec le compte du connecteur se compare à cette attente. Une liste vide ne vaut pas exclusion d’accès.
Le mapping conserve la société avec l’identité de la fiche. Deux numéros de client semblables dans deux sociétés ne désignent pas nécessairement le même objet. Dans notre laboratoire, le marqueur distingue les témoins ; en situation réelle, le dossier doit établir l’origine des données autrement qu’en acceptant les déclarations d’un fichier local.
Donner une portée précise au résultat de la matrice
Une lecture refusée pour ce client, avec cette identité et cette interface, est une observation utile. Elle ne certifie pas automatiquement les autres ressources, toutes les extensions ou toutes les actions publiées. La clôture du projet porte sur le périmètre convenu et sur la revue de configuration associée. Les chemins non testés restent identifiés comme tels.
À l’inverse, lire le témoin de B démontre un écart avec la politique de notre exemple, même si le flux normal ne le demande jamais. Le seuil de sortie de cette recette exige zéro lecture qualifiée d’un témoin exclu ; l’observation est transmise à l’administrateur. Ajouter seulement un filtre dans l’écran de configuration peut éviter une erreur habituelle de sélection ; cela ne corrige pas à lui seul l’autorisation sous-jacente.
Relire les affectations sans confondre société, scope et application
Demander le périmètre des affectations réellement utilisées
Pour les utilisateurs et groupes de sécurité, Microsoft distingue le contenu d’un jeu de permissions de son affectation à une société. La documentation indique qu’une affectation sans société s’applique à toutes. Ce point décrit ce mécanisme documenté ; il ne justifie pas d’inventer la présentation exacte de la fiche applicative d’une version cliente.
Pour l’application S2S, demander à l’administrateur les affectations et leur portée réellement constatées dans l’environnement concerné. Examiner les permissions incluses et les dépendances, plutôt que juger un accès à partir du seul nom du jeu. Le partenaire Business Central valide le paramétrage natif ; l’intégrateur relie cette configuration aux parcours du middleware qu’elle doit permettre.
Ne pas joindre deux colonnes seulement parce qu’elles s’appellent App ID
La référence de la table Access Control décrit User Security ID, Role ID, Company Name, Scope et App ID. Dans ce contexte, App ID désigne l’extension qui fournit le jeu de permissions ; ce n’est pas l’Application Client ID Entra du connecteur. Une jointure improvisée sur ces noms peut produire un rapport vide tout en donnant l’impression d’avoir analysé le compte applicatif.
Scope distingue également un niveau système ou tenant du jeu de permissions ; il ne remplace pas Company Name. Le contrat de collecte doit expliquer les identités manipulées et leurs correspondances. Une extraction lisible mais construite sur la mauvaise clé ne fournit aucune assurance supplémentaire. Faire valider ces correspondances avant de présenter le rapport à l’équipe qui décidera une réduction d’accès.
Utiliser les API d’audit de 2026 avec leur véritable périmètre
Une collecte en lecture seule reste un accès à qualifier
La documentation de la vague 2026 décrit de nouvelles API en lecture seule pour analyser les permissions, avec une disponibilité générale datée du 14 juin. Microsoft prévoit un jeu de permissions dédié et précise qu’il ne doit pas être attribué aux utilisateurs standard. Vérifier la version, la disponibilité et l’identité d’audit autorisée avant d’utiliser cette capacité chez un client.
Ne pas élargir automatiquement le compte d’export pour lui permettre d’auditer ses propres accès. Le besoin de collecte appartient à une fonction d’administration distincte du parcours commercial. Le rapport peut rapprocher affectations, groupes et permissions d’objets ; il ne transforme pas une simple observation de lecture en certification de toutes les opérations possibles.
La société dans l’URL d’audit ne filtre pas tous ses résultats
L’introduction actuelle des Automation APIs présente notamment userPermissionSets, accessControls et expandedPermissionSets. Elle précise que ces endpoints d’inspection sont appelés sous une route de société, alors que leurs résultats ne sont pas limités à cette société. Cette règle concerne ces ressources d’audit ; elle ne doit pas être étendue à toutes les API métier.
La couverture de l’inventaire demande aussi une vérification. La documentation énumère les types de licence inclus dans usersPermissions ; une identité absente de ce résultat ne prouve pas qu’elle ne possède aucun accès. Conserver les limites de chaque extraction dans le dossier, puis compléter la collecte autorisée si la correspondance du compte applicatif n’est pas établie.
Observer une lecture réelle avant de conclure sur les droits
Relier la requête au témoin et à l’identité
La référence REST de lecture d’un client utilise une société et un identifiant de client dans le chemin ; le succès renvoie l’objet correspondant. Pour la recette, l’adaptateur conserve les références nécessaires de la requête et de la réponse, sans recopier tout le payload client. La preuve doit permettre de retrouver quel témoin a été demandé et lequel a été reçu.
Un outil comme Postman peut aider à isoler un appel, mais il faut conserver l’identité prévue pour le service. Une autre identité ou un autre environnement invalide la comparaison. Les contrôles de configuration du worker restent nécessaires : une URL montrée pendant l’atelier n’établit pas que le traitement planifié utilise ensuite le même chemin.
Distinguer un refus d’autorisation d’une réponse inexploitable
Microsoft distingue les familles d’erreurs Authentication, Authorization, BadRequest, Internal et Application pour REST/OData. Conserver la catégorie et le contexte effectivement qualifiés vaut mieux que déduire une cause du seul statut HTTP. Un 403 produit par un intermédiaire non identifié ne fournit pas la même preuve qu’un refus d’autorisation attribué à Business Central.
Le timeout, l’indisponibilité et la latence excessive restent des incidents de lecture à expliquer. Le retry ou le backoff peuvent répondre à certaines erreurs transitoires selon le contrat retenu ; ils ne corrigent pas un accès trop large. Le runbook sépare donc la collecte manquante, le refus attendu et l’écart d’autorisation observé.
Laboratoire : classer les observations des sociétés A et B
Exécuter un modèle de preuves, pas un moteur de permissions
Le fichier company_read_evidence_inventory.py fonctionne avec Python 3.9 ou plus récent et sa bibliothèque standard. Il utilise des objets internes Case et Observation, entièrement fictifs. Ces structures ne sont pas les payloads natifs des API d’audit et les identifiants client-A-42 ou client-B-42 ne sont pas des GUID Microsoft à réutiliser.
Les 37 contrôles couvrent l’identité de recette remplacée par un administrateur, le mauvais environnement, la mauvaise société, le témoin incorrect, les doublons et les observations trop anciennes pour la fenêtre locale choisie. La catégorie d’erreur est fournie au modèle après qualification ; aucun décodeur natif, vérificateur de token ou contrôle d’origine réseau n’est implémenté.
python3 company_read_evidence_inventory.py
# 37 local checks passed. Native Business Central reads: 0;
# HTTP calls: 0; permission changes: 0.Lire les verdicts sans leur attribuer des garanties supplémentaires
Exemple concret du laboratoire : le témoin A est retrouvé, puis une observation 200 contenant le témoin B est fournie au programme. Le verdict excess_read_observed signale la contradiction avec notre politique fictive. Il n’explique pas quelle affectation native a ouvert cet accès et n’autorise aucune modification automatique de Business Central.
Une observation 404 est classée séparément, tout comme l’absence d’observation pour B. Le résultat ne devient jamais « société interdite » par défaut. La fenêtre de 90 unités de temps du test est une convention du laboratoire, avec une horloge entière fournie ; elle ne prescrit aucune durée universelle de validité d’un audit ni de conservation des traces d’un client.
Erreurs fréquentes : déclarer une société protégée sans preuve comparable
Confondre absence de données et absence d’accès
Un résultat vide peut venir du filtre, du mauvais identifiant, d’un objet absent ou d’une lecture non représentative. Le laboratoire exige un témoin reconnu avant de qualifier un succès ; il n’interprète ni l’absence ni un 404 comme une démonstration d’exclusion. Le dossier réel doit expliquer la réponse native et les conditions de la requête.
Un premier signal faible apparaît lorsque la société B n’est testée qu’après suppression du témoin. Le test semble rassurant, mais il a perdu son objet de comparaison. Un second est la répétition d’essais manuels avec un utilisateur différent du service : les observations peuvent être exactes individuellement tout en étant inutilisables pour décider des droits du connecteur.
Conserver trop de droits pour éviter de refaire la recette
Réutiliser un compte commun à plusieurs flux peut simplifier le premier raccordement et rendre ensuite la réduction d’accès délicate. La synchronisation CRM, le reporting et le portail n’ont pas nécessairement les mêmes besoins. Cartographier leurs dépendances avant de modifier les affectations ; retirer un accès sans recetter les autres usages peut bloquer une activité pourtant légitime.
Le coût caché d’un compte trop large apparaît aussi dans le diagnostic : aucune équipe ne sait quelle application dépend de quelle société. Une configuration attribuée, une journalisation sans secrets et un monitoring des refus rendent les changements plus compréhensibles. Ces mesures accompagnent les permissions natives ; elles ne les remplacent pas.
Réduire le périmètre avec l’administrateur puis recetter le flux
Corriger l’affectation identifiée, pas seulement la route visible
Lorsque l’écart est reproduit et les correspondances établies, l’administrateur décide la modification native adaptée. L’intégrateur ajuste séparément les contrôles de sélection du connecteur. Ces interventions peuvent être complémentaires : une application correctement limitée n’empêche pas toutes les erreurs métier à l’intérieur de A, et une bonne sélection de A ne démontre pas l’absence de droits sur B.
Paradoxalement, un contrôle de routage qui refuse B avant tout appel peut masquer une permission native trop large pendant la recette. Il faut donc distinguer le test du garde-fou local et la vérification autorisée des droits réellement exercés. Le rapport conserve le niveau qui a produit chaque refus, afin de ne pas attribuer au serveur une décision prise par le middleware.
Prévoir les demandes déjà engagées
La revue de lecture ne certifie aucune création, aucune idempotence ni aucun rollback d’écriture. Si le compte participe aussi à l’envoi de commandes, qualifier ces parcours et leurs effets séparément avant un changement d’accès. La queue ne doit pas continuer indéfiniment à relancer des opérations devenues interdites ; ses exceptions doivent rejoindre une responsabilité identifiée.
Après réduction, recetter les parcours nécessaires et les exclusions convenues, puis comparer les résultats aux observations précédentes. Une procédure de retour à une configuration approuvée doit tenir compte du risque d’accès qui a motivé le changement. Réactiver des droits larges par simple commodité d’exploitation ne constitue pas une clôture de l’écart.
Plan d’action : décider avec une configuration et des lectures rapprochées
- Décrire les accès demandés par le flux. Le métier choisit les sociétés, ressources et opérations réellement nécessaires. L’intégrateur retrouve l’identité utilisée par le traitement planifié et sa configuration résolue. L’administrateur prépare les témoins et le cadre des vérifications autorisées. La sortie attendue est une matrice compréhensible, avec les parcours acceptés, exclus et non encore qualifiés. Différer les changements de permissions tant que cette attente mélange plusieurs comptes ou plusieurs environnements.
- Rapprocher les affectations et les identités. Le partenaire Business Central confirme les jeux de permissions, leurs dépendances et leur portée dans l’installation. Le responsable de l’audit qualifie les extractions disponibles et leurs limites, notamment la portée des résultats et les identités absentes. Le développeur documente les correspondances entre identifiants Entra, utilisateurs techniques et extensions. Une jointure incertaine reste un écart à traiter ; elle ne produit pas une conclusion d’absence d’accès.
- Observer puis expliquer les résultats contradictoires. L’équipe de recette utilise les témoins convenus et l’identité du connecteur. Elle distingue le refus local, le refus natif qualifié, la donnée absente et l’incident de transport. L’administrateur recherche l’affectation responsable d’une lecture exclue devenue possible. Le dossier conserve les preuves nécessaires avec leur contexte et leur révision, sans collecte générale de fiches clients. Aucune modification d’accès ne part d’un simple statut non expliqué.
- Recetter la correction et attribuer la surveillance. Après la décision administrative, l’intégrateur vérifie les parcours indispensables et les exclusions, puis contrôle les autres usages connus du compte. L’exploitation classe les exceptions et sait quand suspendre un flux plutôt que multiplier ses tentatives. Le seuil de clôture exige une matrice renseignée sur la cohorte convenue, des correspondances validées et des responsabilités de maintenance. Les sociétés ajoutées ultérieurement doivent déclencher une nouvelle qualification de leur accès.
Sources et guides complémentaires pour la revue du compte applicatif
Les références Microsoft derrière les distinctions de périmètre
La documentation S2S pour Business Central distingue l’enregistrement et les permissions applicatives. Les affectations de permissions documentent le périmètre société pour utilisateurs et groupes ; la table Access Control précise le sens de ses identifiants.
Les API d’analyse des permissions de 2026 et l’introduction aux Automation APIs décrivent les collectes évoquées. La lecture REST d’un client et les catégories d’erreurs REST/OData cadrent l’observation. Références consultées le 15 octobre 2026 ; la disponibilité chez un client reste à vérifier.
Séparer accès, migration d’interface et contrat d’échange
La migration des pages Microsoft SOAP dans Business Central 29 traite le choix de l’interface et les pièces métier. Le contrat d’échange ERP et e-commerce précise les responsabilités de transformation et de reprise. Aucun de ces choix ne dispense d’utiliser l’identité prévue pour la recette des accès.
Les 37 contrôles locaux ne vérifient ni les affectations natives, ni l’authenticité d’une réponse, ni la couverture de toutes les ressources du tenant. Ils rendent explicites les observations qui manquent ou se contredisent dans notre scénario. La preuve d’un raccordement réel reste le rapprochement de sa configuration, de ses identités et des lectures autorisées effectuées dans l’environnement concerné.
Conclusion : vérifier ce que le compte peut lire au-delà du parcours prévu
Un connecteur configuré sur A peut rester porteur de droits plus larges. La revue doit distinguer cette sélection de route, les permissions attribuées dans Business Central et les lectures réellement observées. L’identité du service, la société, la ressource et le témoin doivent être retrouvables dans chaque comparaison.
Nous commencerions par une matrice réduite dont les témoins et les attentes sont connus. Une fiche de B lisible malgré son exclusion ouvre un diagnostic d’accès ; un résultat vide ou un 404 ne le ferme pas. Les refus locaux et les refus natifs restent séparés, avec leurs conditions et leurs limites de preuve.
Les nouvelles capacités d’audit peuvent éclairer les affectations, à condition de qualifier leur disponibilité et leur couverture. Une société présente dans l’URL n’en borne pas nécessairement les résultats, et deux identifiants App ID ne désignent pas automatiquement la même application. La qualité de ces correspondances conditionne la décision de correction. Notre expertise d’intégration Microsoft Business Central permet d’organiser cette revue avec le partenaire qui maintient vos objets et vos permissions.
Dawap vous accompagne pour qualifier cette intégration API entre Business Central et vos applications, rapprocher les parcours du connecteur avec les droits vérifiés et préparer une recette avec votre administrateur et votre installateur ERP. L’objectif est un accès attribué au besoin du flux, avec des preuves compréhensibles et des limites de contrôle explicitement conservées.
