Ce qu’il lit, et ce qu’il ne lit pas.

Ce qu’il lit

Seulement ce dont une évaluation a besoin, et toujours uniquement en lecture :

• Les métadonnées des solutions et des composants : quelles tables, flux, applications, plug-ins, rôles et ressources web existent, et comment ils sont configurés.
• Le contenu d’un fichier de solution exporté, lorsqu’il en est fourni un.
• L’usage et l’historique d’exécution, dans la mesure où la connexion y accède : combien de fois un flux a tourné, combien de fois il a échoué, combien de temps une étape de plug-in a pris.
• Les résultats du Power Apps checker de Microsoft, là où il a été exécuté.

Ce qu’il écarte

Certaines choses sont lues au passage et ne sont pas conservées :

• Les secrets trouvés dans une définition sont comptés, jamais stockés et jamais affichés. Un constat dit qu’un secret est présent et où, pas lequel.
• Les identifiants d’une connexion vivent dans Azure Key Vault et sont désignés par leur nom. La base du produit ne contient aucun secret.
• Les données métier des tables ne sont pas lues. Le produit compte des lignes ; il ne les regarde pas.

Ce qu’il refuse de faire

Ce ne sont pas des réglages. Aucune configuration n’active l’un d’eux :

• Il n’écrit jamais dans un environnement Power Platform, dans aucun mode.
• Il ne publie jamais dans Azure DevOps, Jira ou GitHub quoi que ce soit que personne n'a sélectionné, et il n'écrit jamais dans l'environnement qu'il a lu.
• Il ne montre jamais le parc d’une mission à quelqu’un à qui l’accès à cette mission n’a pas été accordé.

Ce que contiennent les documents

Trois choses sortent du produit, et il vaut la peine de savoir exactement ce qu’il y a dans chacune :

• Le classeur. Noms de composants, noms de solutions, les constats et leurs preuves, les estimations et le backlog. Les noms de composants sont le nommage propre du client : traitez le fichier comme vous traiteriez son export de solution.
• Le rapport. La même matière sous forme de récit, plus la liste de ce qui n’a pas pu être vérifié. Des composants sont nommés là où un constat porte sur une chose précise.
• Les éléments de travail. Titres, descriptions et critères d'acceptation, écrits dans le projet Azure DevOps, le projet Jira ou le dépôt GitHub du client lui-même. Rien ne quitte leur tenant qui ne s'y trouvait déjà.

Supprimer une mission

Supprimer une mission supprime ses connexions, ses exécutions, son inventaire, ses constats, ses estimations et son backlog, en une seule opération et sans corbeille. Les éléments de travail déjà publiés dans l'Azure DevOps, le Jira ou le GitHub d'un client leur appartiennent et ne sont pas touchés.

Où il s’exécute

Dans Microsoft Azure, dans une région choisie pour le déploiement, dans l’abonnement propre de Capgemini. La base n’est joignable que par l’identité managée du produit ; il n’y a pas de mot de passe à fuiter, parce qu’il n’y en a pas. La seule chose qui quitte cet abonnement part vers le Power Apps checker de Microsoft, où un fichier de solution est analysé dans une région choisie sur la connexion, et vers Azure OpenAI, qui estime les constats et lit les descriptions quand une exécution est autorisée à utiliser un modèle. Ce déploiement est dans la zone de données UE et Microsoft n'entraîne pas de modèles sur ce qui lui est envoyé.

Cookies sur ce site

Ce site public dépose un cookie, et seulement si vous utilisez l’interrupteur clair/sombre : il retient votre choix. Pas d’analytique, pas de traçage, aucun script tiers et aucune police, image ou feuille de style chargée depuis un endroit qui vous verrait arriver. La connexion dépose un cookie de session, et c’est lui qui vous maintient connecté.