Projets et espace de travail

Accueil · Projets et espace de travail

Objectif

Cette page explique la différence entre Projets, Espace de travail et Agents, puis détaille les réglages projet réellement visibles dans l’application.

Trois surfaces à distinguer

Surface	Quand l’utiliser
Projets	Créer un projet, ouvrir un projet existant, changer de contexte
Espace de travail	Lire le résumé projet, la transparence opérationnelle, les signaux et les réglages de niveau projet
Agents	Lancer un échange en direct avec un agent et lire la sortie structurée du run

En pratique, Projets sert à entrer dans le bon contexte, Espace de travail à le configurer et Agents à l’exploiter.

Le rôle exact du projet actif

Le projet actif est le contexte actuellement appliqué aux pages de travail projet.

Concrètement, il détermine :

• les documents visibles dans Connaissance ;
• les runs lancés dans Agents ;
• les PM Docs, artefacts et diff visibles dans Rapports & artefacts ;
• les runs et événements affichés dans Journal IA ;
• les signaux, intégrations et politiques affichés dans Espace de travail.

Il ne faut donc pas confondre :

• projet actif : contexte opérationnel courant ;
• Portfolio : vue de comparaison multi-projets ;
• All projects : portée éventuelle d’un agent personnalisé visible dans plusieurs projets pour le même compte.

Créer un projet

Le formulaire contient les champs suivants :

• ID projet ;
• Nom ;
• Description ;
• Langue de données par défaut ;
• Langues de données supplémentaires.

Recommandations de saisie :

• choisissez un ID lisible et durable ;
• ne confondez pas langue de données projet et langue d’interface ;
• définissez correctement le périmètre avant d’ouvrir la connaissance ou les agents.

Créateur du projet : droits initiaux et délégation

À la création, le créateur du projet démarre avec le rôle Propriétaire du projet et l’ensemble des permissions projet disponibles. En pratique, c’est donc lui qui peut ouvrir le projet, vérifier la configuration initiale et déléguer ensuite les rôles au reste de l’équipe.

Délégation recommandée juste après la création

1. ouvrez Contrôle d’accès ;
2. ajoutez au moins un autre Propriétaire du projet ou un Chef de projet de confiance ;
3. créez si besoin des rôles personnalisés ciblés plutôt que de multiplier les propriétaires ;
4. attribuez ensuite les rôles aux contributeurs, lecteurs et auditeurs ;
5. relisez enfin les Politiques de gouvernance et les Intégrations du projet pour aligner droits, connecteurs et validations.

Ce que la plateforme protège encore

• l’entrée du créateur reste protégée ;
• le rôle du créateur reste fixe dans l’interface ;
• la délégation se fait par attribution de rôles supplémentaires, pas par suppression de la protection du créateur ;
• pour le détail RBAC, voir Contrôle d’accès et rôles projet.

Ouvrir et changer de projet

Un projet peut être ouvert depuis :

• la page Projets ;
• le sélecteur de projet de la barre supérieure ;
• le contexte récemment mémorisé dans le navigateur.

Lorsque vous changez de projet, les surfaces suivantes se recalent : Connaissance, Agents, Documents PM / Rapports & artefacts, Journal IA, les signaux et les réglages projet.

Ce changement de projet modifie donc réellement le contexte actif utilisé par la recherche documentaire, les conversations agents, les rapports et les traces associées.

Le dernier projet retenu peut être mémorisé localement par le navigateur pour faciliter la reprise, mais cette mémoire locale n’est pas un réglage partagé à toute la plateforme.

L’espace de travail : centre de pilotage du projet

L’Espace de travail réunit dans une même surface :

• le résumé projet ;
• des raccourcis vers Agents, Documents PM et Journal IA ;
• une vue de transparence opérationnelle ;
• les signaux du projet ;
• les onglets de réglage de niveau projet.

L’Espace de travail ne présente plus de carte voix dédiée. Quand une saisie vocale existe encore dans certains environnements, elle est disponible dans Agents, pas comme point d’entrée séparé de l’espace de travail.

Transparence opérationnelle et préparation

L’espace de travail ne sert pas seulement à résumer le projet. Il permet aussi de voir si le projet est prêt à agir :

• présence ou absence de signaux ;
• activité récente ;
• raccourcis vers les brouillons ou livrables liés ;
• préparation des intégrations projet quand elles existent ;
• exposition du fournisseur IA effectif sans ouvrir la configuration tenant.

Utilisez cette zone pour comprendre pourquoi une action ou un import peut être disponible, à confirmer ou bloqué.

Comment arrivent les signaux, digests et brouillons

Dans l’interface, le panneau de signaux du projet relit trois flux partagés pour le projet actif :

• les signaux courants ;
• les digests récents ;
• les brouillons de notification liés à ces signaux.

Lecture utile :

• l’ouverture de l’espace de travail recharge l’état partagé déjà connu pour ce projet ;
• Refresh demande explicitement au système de réévaluer le projet et de tirer les derniers signaux proactifs ;
• Generate digest draft construit une nouvelle synthèse groupée et peut préparer des notifications in_app ;
• ces éléments ne sont donc pas de simples notes locales du navigateur.

Onglets de niveau projet

Onglet	À quoi il sert
Configuration des agents	Paramétrer les agents pour ce projet
Contrôle d’accès	Gérer membres, rôles et permissions de niveau projet
Catégories de documents	Adapter la taxonomie documentaire du projet et la propager aux surfaces documentaires du projet
Politiques de gouvernance	Définir connecteurs, destinations, politiques d’action, profils de rendu et préférences de notification de niveau projet
Intégrations du projet	Relier au projet les intégrations prêtes et autorisées
Actions & approbations	Gérer les demandes d’action, validations et exécution gouvernée

Configuration des agents

Les paramètres confirmés au niveau projet sont :

• status ;
• temperature ;
• max tokens.

Contraintes visibles

• temperature est attendue entre 0 et 2 ;
• max tokens doit être un entier supérieur ou égal à 1.

Historique de configuration

L’interface expose aussi un historique par version avec au minimum :

• numéro de version ;
• statut ;
• température ;
• max tokens ;
• date de création ;
• auteur ;
• Trace ID associé.

Contrôle d’accès

L’onglet Contrôle d’accès administre les membres et rôles projet. Il supporte :

• les rôles standards ;
• les rôles personnalisés ;
• les garde-fous RBAC ;
• la lecture seule pour les profils non autorisés à modifier.

Voir la page dédiée : Contrôle d’accès et rôles projet.

Catégories de documents

Cet onglet sert à aligner la classification documentaire avec le projet. En pratique, la taxonomie projet influence les catégories proposées lors des téléversements et certains sélecteurs documentaires utilisés ensuite dans les surfaces projet.

Effet concret d’une mise à jour

Quand la liste des catégories est modifiée avec succès :

• le sélecteur de catégorie de téléversement dans Connaissance est mis à jour ;
• les sélecteurs et filtres de catégorie dans Documents PM se recalent quand ils utilisent cette taxonomie partagée ;
• le changement reste limité au projet courant.

Exemples pratiques

Gardez une taxonomie courte et stable. Par exemple, au lieu de multiplier les variantes proches, préférez quelques catégories cohérentes comme :

• charte projet ;
• registre des risques ;
• rapport de statut ;
• plan achats ;
• plan de communication.

L’objectif n’est pas d’encoder la version du document dans la catégorie, mais de garder un classement réutilisable entre Connaissance et Documents PM.

Politiques de gouvernance

Cet onglet fixe les règles qui encadrent les décisions, validations et comportements de gouvernance du projet. Utilisez-le avant de publier un livrable ou d’autoriser une action externe gouvernée.

Sous-surfaces visibles dans Politiques de gouvernance

Sous-surface	Ce qu’elle règle
Connecteurs d’exécution	Type de connecteur, statut, mode d’exécution, environnement, scopes et paramètres de contexte
Destinations des artefacts	Destination cible d’un artefact, connecteur associé, caractère actif ou par défaut
Politiques d’action	Rôle concerné, connecteur ciblé, niveau d’action (observe, draft, propose, execute), effet (allow, require_approval, deny) et scopes autorisés
Profils de rendu	Profils de rendu et format de sortie utilisés lors des publications gouvernées
Préférences de notification	Canal, type de notification, mode de digest, seuil de sévérité et activation de la préférence

Exemples de réglages utiles

• exiger une approbation explicite avant une publication vers SharePoint ;
• autoriser la création de ticket Jira seulement au niveau propose pour certains rôles ;
• préparer des préférences signal_digest en in_app pour le suivi interne ;
• laisser les notifications externes email, teams ou webhook dans un chemin approuvé seulement lorsque le connecteur est sain ;
• choisir des profils de rendu séparés pour les publications DOCX et XLSX.

Scénario crédible — projet sensible / diffusion gouvernée

Pour un projet où toute diffusion externe doit être contrôlée, un réglage cohérent ressemble souvent à ceci :

1. Destinations des artefacts : destination SharePoint active avec profil de rendu connu ;
2. Politiques d’action : allow pour observe et draft, mais require_approval pour execute sur les publications et notifications externes ;
3. Connecteurs d’exécution : connecteurs externes visibles seulement pour les rôles réellement autorisés ;
4. Préférences de notification : signal_digest en daily pour l’équipe, signal_alert seulement pour les cas les plus sensibles ;
5. Intégrations du projet : rattachements activés uniquement pour les connecteurs déjà validés au niveau plateforme.

Cette combinaison évite qu’un brouillon, un digest ou une action apparaisse comme directement diffusable alors que le projet attend encore une approbation humaine.

Intégrations du projet

Cet onglet sépare les intégrations techniquement définies au niveau plateforme de celles qui sont réellement utilisables par le projet.

Comment lire cet onglet

L’onglet Intégrations du projet n’est pas l’endroit où l’on configure toute la technique du tenant. Il sert surtout à lire la préparation opérationnelle projet : ce qui est visible pour ce projet, ce qui est prêt, et ce qui reste bloqué avec une raison explicite.

On y retrouve plusieurs familles d’informations :

• Connecteurs d’exécution : options de sortie gouvernée vers des systèmes externes ;
• Fournisseurs d’ingestion : sources d’import consommées ensuite par Connaissance ;
• Transparence d’exécution IA : fournisseur IA effectif et fournisseur sélectionné au déploiement ;
• Posture licences : plan actif, licences commandées, licences utilisées et licences restantes visibles.

Ce que montre l’écran Intégrations du projet

L’écran sépare la préparation technique de la disponibilité projet :

• la configuration plateforme, le rattachement projet, la politique, la permission, l’état de santé et la disponibilité de licence pour l’accès à l’app sont des causes distinctes. Un connecteur peut rester visible en lecture seule pour expliquer pourquoi il est bloqué au lieu de laisser croire qu’il manque ;
• la configuration technique reste dans Administration de la plateforme. Les responsables des paramètres projet peuvent rattacher les intégrations activées et prêtes, tandis que les informations sensibles restent centralisées dans l’administration sécurisée.

Zone	Ce que vous pouvez voir	Comment agir
Connecteurs d’exécution	une liste courante parfois vide, puis un catalogue disponible au rattachement avec Asta Powerproject schedule sync, Azure DevOps delivery project, Jira delivery workspace, Microsoft Project schedule sync, Microsoft Teams collaboration, Outlook executive notifications, SharePoint publication library, Smartsheet portfolio workspace, Webhook event delivery et Wrike delivery workspace	utilisez Bind to project seulement pour les connecteurs déjà activés et prêts au niveau plateforme
Fournisseurs d’ingestion	des fournisseurs comme Smartsheet sheet import et Azure Data Factory evidence pipeline marqués Healthy, puis des fournisseurs disponibles comme SharePoint knowledge import, Azure Blob document ingest, Confluence knowledge import, Jira issue import, SFTP document intake, Microsoft Project schedule import, Wrike task import et Asta Powerproject schedule import	utilisez Validate binding pour revérifier un fournisseur rattaché, Disable pour le fermer côté projet, ou Bind to project pour un fournisseur approuvé

Les cartes fournisseur peuvent afficher Ready, Healthy ou Not configured. Not configured signifie que le fournisseur existe dans le catalogue plateforme, mais qu’il manque encore une source, des identifiants ou une validation de préparation avant l’usage projet.

Pour les champs obligatoires, les probes, le mapping des actions et les limites d’exécution réelle, utilisez la page Connecteurs et intégrations. Ready ou Healthy indique une préparation cohérente, mais ne prouve pas à lui seul qu’un ticket, un message ou un import externe complet a déjà été exécuté.

Causes de blocage affichées

Une intégration projet ou une option d’import peut être bloquée pour cause de :

• politique ;
• permission ;
• état de santé à vérifier ;
• définition plateforme absente ou désactivée ;
• rattachement projet désactivé ou non configuré ;
• configuration ou validation spécifique au fournisseur incomplète.

Comment interpréter un blocage de rattachement

Cause visible	Lecture pratique	Réflexe recommandé
entitlement	libellé hérité pour une intégration bloquée, pas une différence de fonctionnalité Marketplace	vérifiez configuration, validation, état de santé, rattachement, politique, rôle et disponibilité de licence en cas de blocage d’accès
policy	la gouvernance projet interdit ou limite ce flux	relisez Politiques de gouvernance avant de modifier le rattachement
permission	le connecteur existe mais votre rôle ne permet pas de l’activer ou de l’utiliser	contrôlez le rôle projet dans Contrôle d’accès et rôles projet
health	la définition plateforme existe mais sa préparation ou sa disponibilité demandent une vérification	ouvrez l’Administration de la plateforme pour confirmer la définition technique
définition absente ou désactivée	rien n’est réellement prêt au niveau tenant	demandez d’abord la mise en place ou la réactivation plateforme
rattachement projet absent	la plateforme est prête mais le projet ne consomme pas encore l’intégration	activez explicitement le rattachement côté projet

Lecture pratique du rattachement et des licences

• rattachement : le connecteur ou fournisseur existe au niveau plateforme, mais il faut encore le rattacher et l’ouvrir au projet pour qu’il soit consommable dans ce projet ;
• licence : elle détermine si l’utilisateur dispose d’une licence disponible pour accéder à l’app. Les plans Marketplace ne débloquent ni ne bloquent des familles de connecteurs différentes ;
• un connecteur visible mais bloqué ne signifie donc pas qu’il est cassé : l’interface peut justement le laisser visible pour expliquer la raison du blocage.

Si un blocage persiste, ouvrez ensuite Administration de la plateforme pour vérifier la définition technique, puis revenez sur le projet pour confirmer le rattachement et la préparation.

Jira, SharePoint et chaîne des connecteurs

Gardez cette logique simple :

1. Intégrations de la plateforme définit le connecteur ou le fournisseur d’ingestion ;
2. Intégrations du projet expose seulement le rattachement approuvé et prêt ;
3. Politiques de gouvernance décide ce que chaque rôle peut observer, préparer, proposer ou exécuter ;
4. Actions & approbations applique ensuite ces règles lors de la demande réelle ;
5. Documents PM et Journal IA conservent la trace du flux.

Voir la page dédiée : Connecteurs et intégrations.

Actions & approbations

Cet onglet transforme une recommandation en opération contrôlée.

Les états réels à retenir

Dans l’interface, la file et les cartes de synthèse distinguent surtout quatre états :

État visible	Lecture pratique
Prérequis d’exécution	des connecteurs compatibles peuvent exister, mais l’exécution reste bloquée par santé, configuration, rattachement, permission, politique, approbation ou préparation indisponible
En attente d’approbation	la demande a été proposée et attend encore une décision de gouvernance
Prêt à exécuter	la demande est en état approved, mais l’exécution reste une étape distincte
Historique d’exécution	l’action a réellement été exécutée et reste visible comme historique / preuve d’audit

Une action peut donc être en état approved sans être encore en état executed.

Comment lire un onglet qui paraît vide ou incomplet

La visibilité de l’onglet ne signifie pas qu’une action est déjà exécutable. Quand rien de concret ne semble disponible, la lecture la plus utile est souvent :

1. aucun connecteur d’exécution compatible et sain n’est prêt pour ce type d’action ;
2. le rattachement projet n’expose pas encore l’option au projet ;
3. une policy autorise la consultation mais pas la proposition ou l’exécution ;
4. votre permission permet de voir la file, mais pas d’agir ;
5. une approbation est requise et aucune décision n’a encore été prise.

Quand tout est correctement prêt, on s’attend au minimum à voir :

• un type d’action compatible ;
• au moins une option d’exécution saine ;
• un rattachement projet valide ;
• une policy cohérente ;
• un utilisateur autorisé à proposer, approuver ou exécuter selon le cas.

Ce qu’il faut lire dans Execution préparation

Le bloc Execution préparation n’administre pas toute la plateforme. Il résume simplement ce qui est actuellement proposable dans ce projet.

Lecture utile :

• available / healthy : option théoriquement utilisable ;
• blocked by health : le connecteur existe mais n’est pas dans un état opérationnel suffisant ;
• blocked by entitlement : libellé hérité indiquant un blocage ; vérifiez plutôt configuration, validation, rattachement, politique, rôle et disponibilité de licence si l’accès à l’app est bloqué ;
• blocked by policy : la gouvernance du projet bloque le passage ;
• blocked by permission : votre rôle ne suffit pas ;
• aucune option visible : aucun connecteur compatible approuvé n’est actuellement exposé au projet.

Lecture seule ou accès refusé

• lecture seule : l’onglet reste visible mais l’enregistrement est bloqué ;
• accès refusé : la route ou l’action n’est pas disponible pour votre compte.

Cette différence est particulièrement importante pour Contrôle d’accès, Intégrations du projet et les réglages de gouvernance.

Parcours recommandé après création d’un projet

1. ouvrez l’Espace de travail ;
2. vérifiez d’abord le créateur, les membres et les rôles si le projet est collaboratif ;
3. ajustez ensuite les catégories de documents ;
4. relisez les Politiques de gouvernance avant toute diffusion externe ;
5. reliez uniquement les Intégrations du projet réellement prêtes ;
6. chargez ensuite la Connaissance ;
7. passez enfin aux Agents, aux Documents PM et aux Actions & approbations.

Deux scénarios de paramétrage utiles

Scénario 1 — projet neuf minimal

Pour un projet qui démarre, gardez un ordre simple :

1. ajoutez les membres indispensables et vérifiez leurs rôles ;
2. créez une taxonomie documentaire courte dans Catégories de documents ;
3. activez seulement les intégrations déjà validées et vraiment nécessaires ;
4. préparez une gouvernance minimale, par exemple un digest interne et une destination d’artefact par défaut ;
5. chargez ensuite la Connaissance avant d’ouvrir les agents.

Ce scénario évite d’ouvrir trop tôt des connecteurs ou des règles de diffusion qui ne seront pas utilisés immédiatement.

Scénario 2 — projet sensible / diffusion gouvernée

Pour un projet exposé à des notifications externes ou à une publication documentaire formelle :

1. limitez les rôles ayant accès aux connecteurs externes ;
2. préparez une destination SharePoint ou équivalent dans Destinations des artefacts ;
3. appliquez require_approval sur les niveaux d’action qui peuvent produire une diffusion externe ;
4. privilégiez signal_digest pour le suivi courant et réservez les alertes instantanées aux cas critiques ;
5. ne rendez visibles dans Intégrations du projet que les rattachements dont la préparation et la politique sont déjà conformes.

Ce second scénario aligne lecture des signaux, diffusion, approbation et exécution réelle au lieu de laisser l’équipe traiter chaque écran comme une surface indépendante.

Suite

• Contrôle d’accès et rôles projet
• Connaissance, documents et imports
• Gouvernance, décisions et actions
• Connecteurs et intégrations
• Administration Azure et plateforme