Blog · Heterostasia

Gestion de projet à l'ère de l'IA : pourquoi vos équipes ont besoin d'une Définition du Fait

27 juin 2026 · Aliocha Iordanoff

Depuis que les outils d’intelligence artificielle ont intégré les workflows quotidiens, une plainte revient chez les responsables que nous accompagnons : « On produit beaucoup plus, mais on ne sait plus très bien ce qu’on produit. » Ce n’est pas une crise de résultats. C’est une crise de définition.

Quand un collaborateur passe trois heures sur une tâche assistée par IA, la question n’est plus de savoir s’il a travaillé (c’est visible). La question est de savoir si ce qu’il a produit correspond à ce qui était attendu. Et cette question-là, l’IA ne peut pas y répondre à sa place. Elle n’a pas accès à la définition de « terminé » que votre organisation s’est tacitement construite au fil des années, sauf si vous la lui avez explicitement donnée.

C’est là qu’intervient la Définition du Fait.

Qu’est-ce qu’une Définition du Fait ?

La Définition du Fait (souvent abrégée DdF) est un mécanisme emprunté au développement logiciel agile et adapté à la gestion de projet généraliste. Son principe est direct : pour chaque tâche qui compte, on définit d’avance, sous forme de critères vérifiables, ce que « terminé » signifie.

Une tâche bien construite se décompose en deux parties distinctes.

Le titre formule le travail à accomplir sous la forme « Portée : action ». Il nomme l’objet sur lequel on agit et ce qu’on en fait.

La Définition du Fait liste les critères qui permettront de vérifier objectivement que la tâche est achevée. Ces critères ne décrivent pas le processus : ils décrivent l’état attendu du livrable. Quelques exemples pour la première tâche ci-dessus :

Ces critères peuvent être cochés. C’est ce qui les distingue d’une description vague : on peut dire avec certitude si chacun est satisfait ou non. Un critère comme « le texte est de bonne qualité » n’est pas une DdF, c’est un vœu. Un critère comme « le ton est adapté au registre B2B professionnel, sans formules condescendantes ni jargon technique non défini » en est une.

Pourquoi l’IA rend cette discipline incontournable

L’IA accélère l’exécution. Elle réduit le temps nécessaire pour produire un premier jet, une synthèse, un plan, un brouillon d’email. Mais cette accélération ne touche pas à la question de savoir ce qu’on exécute.

Dans un workflow sans IA, la lenteur jouait un rôle régulateur discret. Le temps passé à rédiger un document forçait une confrontation avec ce qui était flou : on buttait sur les imprécisions, on relisait, on se demandait si on allait dans la bonne direction. La friction produisait de la réflexion. Avec l’IA, cette friction disparaît. Un premier jet arrive en trente secondes, convaincant, bien structuré. La tentation est grande de le valider trop vite.

Le résultat, que nous observons régulièrement dans les organisations que nous accompagnons : des équipes qui produisent deux à trois fois plus de livrables, dont une part significative doit être reprise parce que la cible n’était pas suffisamment définie au départ. Le gain de temps à la production se transforme en coût de correction.

Il y a une deuxième raison, plus structurelle. L’IA produit à partir de ce qu’on lui dit. Si vous lui demandez de rédiger une note de cadrage, elle produira une note de cadrage, mais la note qu’elle produira sera calibrée sur sa représentation générique de ce qu’est une note de cadrage, pas sur vos standards internes, votre niveau d’exigence, les points de vigilance propres à votre secteur, ni les attentes particulières de votre commanditaire. Pour que l’IA soit réellement utile, elle a besoin que vous lui donniez accès à votre définition de « bien fait ». Et pour lui donner cet accès, vous devez d’abord l’avoir formalisé vous-même.

La Définition du Fait n’est donc pas une couche de bureaucratie supplémentaire. C’est le document qui rend votre expertise transmissible aux membres de votre équipe comme aux outils qui les assistent.

La confusion entre le faire et le fait

Il vaut la peine de nommer une confusion fréquente dans les organisations : celle entre « avoir travaillé sur quelque chose » et « avoir terminé quelque chose ».

Dans la plupart des outils de gestion de tâches, une tâche passe de « en cours » à « terminé » sur la base d’un auto-déclaratif. Quelqu’un coche la case. Ce geste est souvent interprété comme « j’ai passé du temps là-dessus » plutôt que « le livrable attendu est prêt selon les critères définis ». La différence semble anodine. Elle ne l’est pas.

Elle crée ce qu’on pourrait appeler le problème de la tâche zombie : une tâche officiellement terminée dont le travail réel n’est pas achevé, ou dont le résultat ne correspond pas aux attentes du commanditaire. Dans les équipes qui utilisent l’IA intensivement, les tâches zombies se multiplient parce que la vitesse d’exécution donne l’illusion que « traiter » équivaut à « terminer ».

La Définition du Fait est le seul mécanisme qui permet de distinguer les deux. Tant qu’au moins un critère n’est pas satisfait, la tâche n’est pas terminée, quel que soit le temps passé, quel que soit l’outil utilisé.

Comment construire une Définition du Fait

La construction d’une DdF suit quelques règles simples, mais exige une discipline réelle.

Écrire les critères avant de commencer le travail. C’est la règle la plus importante, et la plus souvent contournée. Une DdF écrite après coup est une description de ce qui a été fait, pas de ce qui était attendu. Elle inverse la logique. La DdF s’écrit au moment de la planification, quand la tâche est créée ou assignée.

Formuler en termes d’état du livrable, pas d’actions. « Avoir envoyé le document pour relecture » n’est pas un critère de fait : c’est une action. « Le document a reçu les commentaires d’au moins un relecteur et les corrections ont été intégrées » est un critère de fait. On peut avoir accompli l’action sans que le travail soit réellement terminé.

Calibrer le niveau de détail au niveau d’enjeu. Pour une tâche de routine bien connue de l’équipe, deux ou trois critères suffisent. Pour une tâche nouvelle, complexe ou à fort enjeu, cinq à huit critères sont justifiés. L’erreur à éviter est le catalogue exhaustif qui transforme la DdF en procédure : l’objectif est de définir l’état attendu, pas de décrire chaque geste.

Impliquer le commanditaire dans la rédaction des critères. Quand une tâche est assignée par quelqu’un à quelqu’un d’autre, les deux parties ont souvent des représentations différentes de ce que « terminé » signifie. La DdF est le moment de rendre cette différence visible et de la résoudre avant le travail, plutôt qu’après.

Dans la pratique : IA et DdF

Supposons qu’un chargé de développement commercial doit préparer une proposition pour un prospect. La tâche est créée avec le titre : « Proposition commerciale : Groupe Renard, accompagnement 6 mois ». Sa DdF pourrait ressembler à ceci :

Avec cette DdF en main, le chargé peut utiliser l’IA pour produire un premier jet. Il lui donnera le contexte du prospect, le gabarit, les enjeux clés, et il obtiendra une base de travail. Mais c’est la DdF qui lui permet ensuite d’évaluer ce premier jet avec méthode : est-ce que les trois enjeux sont bien traités ? Le ton est-il juste ? Y a-t-il des termes à clarifier ? Sans la DdF, l’évaluation reste subjective. Avec elle, elle devient systématique.

Ce passage de « ça me semble bien » à « ça satisfait ou non chacun de ces critères » est exactement ce que l’IA exige. Non pas parce qu’elle est exigeante, mais parce qu’elle produit vite et que la vitesse sans boussole mène au bruit.

La DdF comme interface entre humains et agents

L’évolution actuelle des outils va au-delà de l’assistance à la rédaction. Les organisations qui vont le plus loin dans l’intégration de l’IA travaillent avec des agents, des systèmes capables d’accomplir des séquences d’actions de façon autonome : rechercher de l’information, rédiger un document, mettre à jour une fiche, envoyer un rapport. Un agent reçoit une tâche et la traite de bout en bout, sans supervision humaine à chaque étape.

Pour qu’un agent produise un résultat acceptable, il a besoin de comprendre ce que signifie « acceptable ». Cette compréhension ne peut pas reposer sur l’intuition : les agents n’en ont pas. Elle doit être explicite, structurée, transmissible. En d’autres termes, elle doit ressembler à une DdF.

Les équipes qui ont déjà formalisé leurs Définitions du Fait se trouvent dans une position avantageuse quand elles commencent à travailler avec des agents. Leurs DdF deviennent naturellement les critères de validation que l’agent peut utiliser pour évaluer son propre travail, ou que l’humain peut utiliser pour vérifier ce que l’agent a produit. Le travail de formalisation, qui semblait d’abord destiné à clarifier les échanges internes, se révèle être exactement le format que l’IA agentique exige.

Celles qui n’ont pas fait ce travail se heurtent à une limite concrète : l’agent produit quelque chose, mais elles ne savent pas exactement si c’est ce qu’elles voulaient, ni comment lui indiquer ce qui manque. La Définition du Fait est le vocabulaire partagé entre les humains et les agents. Sans lui, la délégation reste floue, et une délégation floue à un outil rapide produit des volumes de travail mal orienté.

Ce que la DdF révèle sur votre organisation

Mettre en place les Définitions du Fait dans une organisation est rarement un travail purement technique. C’est souvent un travail d’explicitation : on découvre, en essayant d’écrire les critères, que les standards attendus n’ont jamais été formalisés. Que « une bonne synthèse » veut dire des choses différentes selon les équipes. Que le commanditaire et l’exécutant ne partagent pas la même représentation du livrable.

Cette découverte n’est pas un problème créé par la DdF : c’est un problème qu’elle révèle. Il existait avant, mais restait invisible parce que les ajustements se faisaient en temps réel, dans les échanges informels, par itérations successives. Avec l’IA, ces itérations coûtent moins cher à produire, ce qui pourrait faire croire qu’on peut s’en passer, mais leur coût invisible (temps de revue, décisions remises, charge cognitive de coordination) reste entier.

La Définition du Fait est, à cet égard, un outil de lisibilité organisationnelle autant qu’un outil de gestion de projet. Elle rend explicite ce qui définit un travail bien fait dans votre organisation. Cette explicitation bénéficie à vos équipes, qui savent où elles vont. Elle bénéficie à vos outils d’IA, qui ont un contexte précis pour travailler. Et elle bénéficie à votre organisation, qui capitalise sur ses standards plutôt que de les réinventer à chaque projet.

Par où commencer

Si vous voulez introduire la Définition du Fait dans votre équipe sans créer de résistance, commencez modestement.

Choisissez une dizaine de tâches récurrentes à fort enjeu, des tâches qui reviennent souvent et pour lesquelles des incompréhensions ou des reprises ont déjà créé des frictions. Réunissez les personnes concernées (commanditaires et exécutants) et construisez les DdF ensemble, en partant d’exemples concrets tirés du passé. Quand une tâche de ce type a bien fonctionné, qu’est-ce qui la distinguait ? Quand elle a créé des problèmes, qu’est-ce qui manquait ?

Ces premières DdF n’ont pas besoin d’être parfaites. Elles ont besoin d’être utilisées. La pratique affinera les critères. Ce qui compte, dans un premier temps, c’est d’instaurer le réflexe : avant de commencer une tâche, définir ce que « terminé » veut dire.

Ce réflexe, une fois ancré, transforme la façon dont votre équipe travaille, avec ou sans IA. Avec l’IA, il transforme aussi la façon dont vous pouvez déléguer : à un collaborateur, à un agent, ou aux deux ensemble.

C’est précisément ce travail de structuration que nous accompagnons dans le cadre de notre diagnostic IA et contextes organisationnels. Notre approche en détaille les étapes. Avant d’optimiser les outils, il faut rendre explicite ce qui doit rester stable : les standards, les critères, les définitions. C’est le fondement sur lequel une intégration durable de l’IA peut se construire.