La nouvelle version du Configurateur Jint s'appuie sur une application Entra ID unique, Jint Intranet, qui remplace progressivement les applications dédiées à chaque module. Cet article explique quelles autorisations sont demandées, à quel moment, pourquoi, et ce que ce modèle garantit pour la sécurité de votre tenant Microsoft 365.

Sommaire

1. Ce qui change : une seule application
2. Les deux versions du Configurateur coexistent
3. Permissions déléguées : le principe et ses garanties
4. Les autorisations demandées à la connexion
5. Les autorisations demandées au fil de l'usage
6. Les autorisations sur votre ressource SharePoint
7. Comprendre AllSites.FullControl
8. Ce que Jint ne fait pas et ne stocke pas
9. Approuver les demandes d'autorisations
10. Questions fréquentes

1. Ce qui change : une seule application

Historiquement, chaque brique fonctionnelle de Jint disposait de sa propre inscription d'application dans Entra ID (Jint Configurator, Jint Administration, Jint Site Engine, Jint Contribution Center...). Chaque nouveau module signifiait donc une nouvelle application à identifier, à approuver et à suivre pour votre DSI.

Nous unifions ce modèle. Les fonctionnalités du Configurateur convergent vers une seule application : Jint Intranet.

Concrètement, pour vous :

• Un seul point de contrôle. Une inscription d'application, un seul écran de consentement à auditer, une seule entrée dans vos Applications d'entreprise pour révoquer l'accès si vous le souhaitez.
• Ce n'est pas une application de plus, c'est la dernière. Les autorisations demandées ici ne s'ajoutent pas à un empilement : elles le remplacent. À terme, les applications par module disparaissent.
• Les demandes suivantes seront ponctuelles, jamais une nouvelle application. Quand une fonctionnalité a besoin d'une autorisation supplémentaire, elle vous la demande au moment où vous l'utilisez, sur cette même application. Vous ne verrez plus apparaître d'application Jint « à côté ».

Ce choix suit le principe du consentement incrémental de la plateforme d'identité Microsoft : plutôt que de tout demander au premier jour « au cas où », l'application ne demande une autorisation qu'à l'instant où la fonctionnalité concernée en a réellement besoin.

2. Les deux versions du Configurateur coexistent

Vous n'êtes pas contraints d'accorder ces autorisations pour continuer à travailler.

L'ancien Configurateur et le nouveau fonctionnent en parallèle, avec les mêmes données de configuration. Vous choisissez donc votre rythme :

• Vous approuvez les autorisations : vos administrateurs accèdent au nouveau Configurateur et à ses fonctionnalités, sur l'application unique Jint Intranet.
• Vous ne les approuvez pas encore : l'ancien Configurateur reste pleinement opérationnel avec les autorisations déjà en place. Votre intranet et vos utilisateurs finaux ne sont pas affectés.

Rien ne se casse et rien ne se perd : votre configuration existante reste la même, quelle que soit la version utilisée. Cela vous laisse le temps de faire valider le nouveau périmètre par votre DSI ou votre comité sécurité avant de basculer.

3. Permissions déléguées : le principe et ses garanties

Toutes les autorisations décrites dans cet article sont déléguées. L'application agit toujours pour le compte de l'utilisateur connecté et ne peut jamais dépasser ce que cet utilisateur est autorisé à faire lui-même.

• Jint ne peut rien faire sans qu'un utilisateur soit authentifié.
• Le périmètre d'accès est exactement celui de l'utilisateur connecté : ni plus, ni moins.
• Un utilisateur en lecture seule sur un site reste en lecture seule via Jint.
• Un compte désactivé ou restreint ne peut pas utiliser Jint pour contourner ces restrictions.
• Vos stratégies d'accès conditionnel et vos contrôles de tenant s'appliquent intégralement.
• Aucune escalade de privilège n'est possible, conformément au standard OAuth 2.0 implémenté par la Microsoft Identity Platform.

À lire pour approfondir : Vue d'ensemble des autorisations Microsoft Graph et Étendues et autorisations dans la plateforme d'identités Microsoft.

4. Les autorisations demandées à la connexion

Ces deux autorisations sont demandées une seule fois, à la première connexion de chaque utilisateur au Configurateur. Elles constituent le socle minimal pour ouvrir une session.

5. Les autorisations demandées au fil de l'usage

Ces autorisations Microsoft Graph sont demandées au moment où vous ouvrez l'écran qui en a besoin, et pas avant. Si vous n'utilisez jamais une fonctionnalité, l'autorisation associée n'est jamais demandée.

Ouverture de l'onglet Rôles et Permissions

Ouverture de l'onglet Traducteur 

Deux points d'attention utiles à votre DSI :

• User.ReadBasic.All est volontairement l'étendue la plus restreinte permettant la recherche d'utilisateurs : elle donne accès aux propriétés de base d'un profil (nom, e-mail, poste, photo), pas à l'ensemble du profil comme le ferait User.Read.All.
• Sites.Read.All est une autorisation de lecture. Elle sert à trouver et identifier des sites, jamais à en modifier le contenu.

6. Les autorisations sur votre ressource SharePoint

Certaines actions ne passent pas par Microsoft Graph mais directement par votre ressource SharePoint (https://<votre-tenant>.sharepoint.com).

7. Comprendre AllSites.FullControl

Cette dénomination peut inquiéter au premier regard. Elle mérite une lecture précise.

En contexte délégué, AllSites.FullControl ne confère pas à l'application un contrôle total et autonome sur vos sites SharePoint. Elle autorise l'application à effectuer, pour le compte de l'utilisateur connecté, les actions que cet utilisateur pourrait déjà réaliser lui-même dans l'interface SharePoint. Le plafond reste toujours celui des droits de l'utilisateur.

Autrement dit :

• Un utilisateur sans droits d'administration sur un site ne pourra pas, via Jint, y effectuer d'action d'administration.
• Un utilisateur dont le compte est désactivé ou restreint ne pourra pas se servir de Jint pour contourner ces restrictions.
• Vos stratégies d'accès conditionnel s'appliquent sans exception.

Pourquoi cette étendue est-elle nécessaire ? Activer l'Expérience unifiée sur un site ou appliquer un modèle avec l'Usine à sites suppose d'écrire des actions personnalisées au niveau du site, et d'intervenir sur plusieurs collections de sites. Le mode délégué permet à ces fonctionnalités d'opérer sur l'ensemble des sites auxquels l'utilisateur a déjà accès, sans exiger une approbation site par site.

8. Ce que Jint ne fait pas et ne stocke pas

• Aucune permission applicative. Le Configurateur n'utilise que des permissions déléguées. Il ne peut donc jamais agir en dehors d'une session utilisateur. (Seule exception dans l'écosystème Jint, documentée séparément : l'application Mozzaik365 Deployment, limitée au(x) site(s) hébergeant le(s) catalogue(s) d'applications SharePoint, pour le déploiement des packages.)
• Aucun stockage de contenu ni de données personnelles sur nos serveurs. Le Configurateur lit les informations depuis vos services Microsoft 365 au moment de l'affichage, via les API sécurisées de Microsoft Graph et SharePoint.
• Aucun accès à vos e-mails, à vos fichiers ou à vos calendriers dans le périmètre décrit ici. Le Configurateur est un outil de configuration : il manipule des paramètres, des audiences et des références de sites.
• Les seules données conservées sont des données de configuration et d'usage anonymisées et agrégées, transmises via une connexion sécurisée vers un espace de travail Azure dédié, hébergé dans un datacenter certifié Microsoft. Elles servent exclusivement à l'analyse de performance et à l'amélioration du service. Elles ne sont jamais utilisées à des fins publicitaires, ni partagées avec des tiers.

9. Approuver les demandes d'autorisations

Deux cas de figure selon le type d'autorisation.

a. Consentement administrateur sur l'application Jint Intranet

Le consentement d'un administrateur Entra ID est nécessaire pour déployer l'application à l'échelle de votre organisation. Il s'effectue une fois, sur l'écran de consentement présenté à la première connexion d'un administrateur, ou depuis le centre d'administration Microsoft Entra (Applications d'entreprise > Jint Intranet > Autorisations).

Si votre tenant autorise le consentement utilisateur, les étendues incrémentales décrites en section 4 peuvent être accordées individuellement par chaque utilisateur. Si le consentement utilisateur est désactivé, un administrateur peut les approuver en une fois pour toute l'organisation.

b. Autorisations approuvées côté SharePoint

Les autorisations utilisées par les composants SharePoint de Jint s'approuvent depuis le centre d'administration SharePoint :

1. Dans le centre d'administration Microsoft 365, section Centres d'administration, sélectionnez SharePoint.
2. Dans le menu, ouvrez Gestion avancée puis Gestion de l'API.
3. Sélectionnez les demandes en attente de la solution Jint, une par une, et approuvez-les.

Documentation Microsoft : Connect to Azure AD-secured APIs in SharePoint

10. Questions fréquentes

Pourquoi de nouvelles autorisations apparaissent-elles alors que j'utilise déjà Jint ?

Parce que nous regroupons sur une application unique ce qui était éclaté entre plusieurs. La demande que vous voyez consolide des accès déjà accordés ailleurs. C'est une opération de simplification, pas une extension de périmètre.

Devrai-je approuver une nouvelle application Jint à chaque module ? 

Non. C'est précisément l'objet de ce changement. Les besoins futurs se traduiront par des demandes d'étendues ponctuelles sur l'application Jint Intranet, jamais par une nouvelle inscription d'application.

Puis-je continuer avec l'ancien Configurateur ? 

Oui, aussi longtemps que nécessaire. Les deux versions coexistent et partagent la même configuration. Tant que les autorisations ne sont pas accordées, l'ancien Configurateur continue de fonctionner normalement, sans impact pour vos utilisateurs finaux.

Puis-je refuser une autorisation ? 

Oui. Comme le consentement est incrémental, refuser une étendue désactive la fonctionnalité qui en dépend, sans bloquer le reste du Configurateur. À noter : Sites.Read.All est sollicitée par la quasi-totalité des écrans, son refus limite donc fortement l'usage.

Comment révoquer l'accès ? 

Depuis le centre d'administration Microsoft Entra : Applications d'entreprise > Jint Intranet > Autorisations, ou en supprimant l'application d'entreprise. L'accès est coupé immédiatement.

Ces autorisations donnent-elles à Jint accès à des données auxquelles mes utilisateurs n'ont pas accès ? 

Non. En mode délégué, c'est structurellement impossible : chaque appel est exécuté avec le jeton de l'utilisateur connecté et se heurte exactement aux mêmes contrôles d'accès que lui.

Une question sur le périmètre exact des autorisations dans votre contexte ? Contactez le support Jint, nous fournissons volontiers le détail par fonctionnalité à votre DSI.