Pourquoi le contexte est crucial pour les assistants IA de projet

Un assistant IA ne peut pas répondre de manière fiable à une question propre au projet s'il ne voit que le dernier message. Il lui faut des éléments pertinents : travail actuel, objectifs, décisions, documents, dépendances, permissions et changements récents.

Davantage de contexte n'est pas automatiquement préférable. Un contexte utile doit être pertinent, actuel, autorisé, vérifiable et assez limité pour être interprété correctement.

Ce que le mot « contexte » recouvre

Plusieurs systèmes différents sont souvent réunis sous ce terme :

• Contexte du prompt — instructions et informations incluses dans la requête actuelle au modèle ;
• Contexte récupéré — cartes, documents, commentaires, décisions ou métriques recherchés pour une question précise ;
• État de la conversation — échanges antérieurs conservés par l'application hôte ;
• Mémoire opérationnelle — faits ou préférences approuvés et conservés entre plusieurs sessions ;
• Résultats de tools — données vivantes renvoyées après un appel API ou MCP ;
• Entraînement du modèle — modification des paramètres du modèle pendant le préentraînement ou le fine-tuning.

Ces mécanismes ne sont pas interchangeables. Consigner une décision projet n'en fait pas automatiquement une donnée d'entraînement. Le plus souvent, la décision reste dans le système projet et est récupérée au moment de l'exécution lorsqu'elle devient pertinente.

Cette distinction compte pour l'exactitude, la confidentialité, la conservation et les attentes des utilisateurs.

Pourquoi les réponses génériques apparaissent

Demandez « que faut-il prioriser ? » sans éléments projet et le modèle ne peut fournir que des principes généraux. Une réponse utile exige des faits comme :

• l'objectif et l'échéance actuels ;
• le travail actif et les personnes responsables ;
• les dépendances et blocages ;
• les contraintes clients, techniques ou réglementaires ;
• les décisions antérieures et leur justification ;
• la capacité disponible et les engagements explicites.

Même avec ces éléments, le modèle ne doit pas présenter une recommandation comme une vérité objective. La priorisation contient un jugement sur la valeur, le risque et la stratégie qui n'est pas toujours entièrement représenté dans le système.

Les cinq qualités d'un bon contexte projet

1. Pertinence

Récupérez les éléments liés au projet, à l'objectif et à la question actuels. Envoyer tout le workspace augmente le bruit et le risque d'utiliser un fait sans rapport.

2. Fraîcheur

Indiquez quand une carte, un document, une métrique ou une décision a été mis à jour. Une réponse soignée fondée sur une spécification obsolète est pire qu'un message explicite indiquant que l'information actuelle manque.

3. Autorité

Toutes les sources n'ont pas le même poids. Une décision d'architecture approuvée doit primer sur une ancienne suggestion dans le chat. L'état vivant du board doit primer sur un rapport de statut copié le mois précédent.

4. Attribution

Les affirmations importantes doivent renvoyer à la carte, au document, au commentaire, à la décision ou au run qui les soutient. L'utilisateur peut ainsi vérifier la réponse et corriger la source de vérité.

5. Contrôle d'accès

Le contexte doit être filtré avant d'atteindre le modèle. L'identité connectée, l'appartenance au projet, les permissions documentaires, les scopes du token et les règles de l'agent déterminent ce qui peut être récupéré.

Un modèle de contexte pragmatique

État actuel du delivery

Le board fournit cartes, statuts, responsables, labels, échéances, dépendances, commentaires et mouvements récents. Il permet de répondre à ce qui est actif ou bloqué.

Objectifs et priorités

Un assistant a besoin du résultat attendu, pas seulement d'une liste de tâches. Sans cela, il risque d'optimiser la fermeture de cartes au détriment de la valeur recherchée.

Documents et décisions

Spécifications, notes de design, comptes-rendus et décisions expliquent pourquoi le travail prend cette forme. Gardez-les proches du delivery et affichez leur date de revue ou de mise à jour.

Preuves du runtime

Missions d'agents, runs de pipelines, erreurs, propositions et approbations montrent ce qui s'est réellement produit. Un statut « agent terminé » reste une preuve faible si aucun résultat n'a atteint le projet.

Équipe et policy

Rôles, permissions, accès aux tools, mode d'autonomie et règles d'escalade définissent l'action adaptée. Ils ne doivent pas être déduits des intitulés de poste ou des patterns d'activité.

Comment produire une réponse contextuelle

Un workflow fiable suit ces étapes :

1. Résoudre l'identité et le périmètre — déterminer l'utilisateur ou l'agent, le workspace, le projet et les permissions.
2. Interpréter la demande — identifier la décision, l'artefact ou l'action attendue.
3. Récupérer les éléments candidats — interroger le board, les documents, les décisions et l'état runtime pertinents.
4. Classer et compresser — conserver les éléments utiles avec leurs liens et timestamps.
5. Générer avec des limites — séparer faits, déductions, contexte manquant et recommandations.
6. Demander une approbation ou exécuter — appliquer la policy liée à l'identité et à l'action.
7. Consigner le résultat — ramener les changements, erreurs et décisions dans la source de vérité.

Omettre la première ou la dernière étape crée de vrais risques : un contexte non autorisé peut atteindre le modèle, ou un workflow apparemment terminé ne jamais mettre à jour le projet.

Exemples

Question de statut

Faible : « Le projet semble avancer, mais surveillez les blocages. »

Sourcée : « La validation de la release attend la carte SP-47. Son pipeline lié a échoué aujourd'hui et aucun retry n'est enregistré. Alex possède la release. »

La seconde réponse n'est utile que si chaque affirmation renvoie à la carte, au run et au responsable actuels.

Recherche d'une décision

Faible : « Comparez les avantages de Redis et Memcached. »

Sourcée : « La décision ADR-14 a retenu Redis pour le support de plusieurs types de données. Le nouveau besoin semble lié, mais ADR-14 n'a pas été revu depuis six mois. Confirmez que ses contraintes s'appliquent encore. »

L'assistant retrouve un précédent sans prétendre qu'il tranche automatiquement le nouveau choix.

Signal de risque

Faible : « Alice est peut-être surchargée. »

Sourcée : « Alice possède quatre cartes actives, dont deux avec une échéance cette semaine. Aucune donnée de capacité n'est disponible : le risque de surcharge ne peut pas être confirmé. »

Cette formulation évite de transformer un nombre de cartes en jugement de performance ou de disponibilité.

MCP et le contexte projet

Le Model Context Protocol fournit aux hôtes IA compatibles une méthode standard pour découvrir les tools, resources et prompts exposés par un serveur. Un serveur projet peut utiliser MCP pour renvoyer des données vivantes et structurées, puis proposer des actions limitées.

MCP n'envoie pas automatiquement « tout ce dont l'IA a besoin ». L'hôte choisit les capacités utilisées, le serveur autorise chaque requête et les clients diffèrent par leurs transports et fonctions. Consultez le guide d'intégration MCP pour le modèle d'identité et de permissions de Stellary.

Les risques liés au contexte

Sources périmées ou contradictoires

Deux documents peuvent se contredire, ou une décision avoir été remplacée sans marqueur clair. L'assistant doit exposer le conflit au lieu de choisir silencieusement une source.

Récupération excessive

Les grandes fenêtres de contexte ne suppriment pas le besoin de sélection. Un contexte excessif peut masquer le fait décisif, augmenter le coût et exposer des données étrangères à la tâche.

Injection de prompt

Documents, commentaires, sites et résultats de tools sont des entrées non fiables. Leur contenu ne doit pas remplacer la policy système, les permissions ni la demande de l'utilisateur.

Déductions sensibles

Ne déduisez pas la performance, la santé, la disponibilité ou l'intention d'une personne depuis ses traces d'activité. Le contexte projet sert la coordination, pas une surveillance cachée.

Mémoire sans gouvernance

Le contexte conservé a besoin d'un responsable, d'une durée de rétention, d'un chemin de modification et d'un périmètre clair. Une préférence mémorisée peut devenir fausse ; une règle propre à un projet peut devenir dangereuse ailleurs.

Comment améliorer la qualité du contexte

• Donnez à chaque projet un objectif clair et un responsable.
• Maintenez à jour le statut, le propriétaire et les blocages des cartes.
• Reliez les décisions au travail qu'elles modifient.
• Ajoutez une date de revue et un responsable aux documents importants.
• Utilisez des champs typés pour les faits qui pilotent des règles déterministes.
• Conservez les liens sources dans les briefs et recommandations IA.
• Rendez le contexte manquant explicite au lieu de demander au modèle de combler les trous.
• Testez la récupération avec les permissions de vrais utilisateurs et agents.
• Consignez les corrections afin d'améliorer les données sources ou la logique de récupération.

Ce qu'il faut mesurer

Évaluez le système de contexte, pas la fluidité de la réponse :

• taux de correction factuelle ;
• part des affirmations importantes accompagnées d'une source ;
• âge des documents et décisions récupérés ;
• récupération de données non autorisées ou sans rapport ;
• temps nécessaire pour vérifier une réponse ;
• actions en échec faute de contexte ;
• changements ayant effectivement atteint la source de vérité.

Le contexte transforme un modèle généraliste en assistant projet uniquement lorsque le système qui l'entoure récupère les bons éléments, applique les accès, expose l'incertitude et ferme la boucle opérationnelle. Pour le modèle plus large, consultez Qu'est-ce que la gestion de projet par IA ?.