Base de connaissances projet : mieux planifier grâce aux projets terminés

La plupart des estimations viennent de la mémoire. La cheffe de projet pense au dernier projet similaire, ajoute un peu de sécurité et saisit un chiffre. Pendant ce temps, les valeurs réelles dorment dans l'archive, sous forme de données réelles des projets terminés. Une base de connaissances projet rend ces données consultables pour chaque nouvelle planification.

Ce que vous y gagnez

Chaque offre commence par la même question : combien de temps cela prend-il vraiment, et combien cela nous coûte-t-il ? Une base de connaissances répond à partir de vos propres données et vous apporte quatre avantages.

• Des estimations de durée plus précises. Chaque tâche reçoit la durée que des tâches comparables ont réellement demandée, ventilée par type, fournisseur, administration ou saison.
• Des marges justifiées. Au lieu d'ajouter dix pour cent partout, vous placez la réserve derrière les tâches dont la durée varie dans vos données.
• Des coûts de conception prévisibles. Vous connaissez le facteur de sous-estimation de votre équipe sur son propre effort et chiffrez offres et honoraires en conséquence.
• Moins de travail supplémentaire. Les problèmes connus figurent déjà dans le registre initial du projet suivant, avec la mesure qui a fonctionné la dernière fois.

L'archive d'exemple de ce guide montre l'ampleur de l'effet : douze projets de construction d'une agence d'architecture de 2021 à 2026, environ 1 350 tâches avec valeurs planifiées et réelles. Nous avons construit cette archive pour que chaque chiffre de cet article reste vérifiable ; ses schémas, toute agence du secteur de la construction les connaît. L'effet apparaît le plus nettement sur deux crèches pour le même maître d'ouvrage public. Pour la crèche Soleil, l'agence a estimé en 2022 à partir de son expérience. Lorsqu'elle a planifié la crèche Arc-en-ciel deux ans plus tard, les valeurs réelles des projets précédents ont alimenté le planning.

La différence tient à la durée d'autorisation, à la consultation et à la période de gros œuvre : l'agence les a planifiées avec les leçons des projets précédents. Sur l'ensemble de l'archive, le constat se confirme. Les sept premiers projets se sont terminés en moyenne avec 23 pour cent de retard par rapport à leur durée prévue. Pour les trois suivants, planifiés avec les fournisseurs, bureaux d'études et durées administratives issus de l'analyse, le retard est tombé à 8 pour cent.

La théorie : pourquoi les projets apprennent rarement des projets

« Ceux qui ne peuvent se souvenir du passé sont condamnés à le répéter. »
George Santayana, The Life of Reason, 1905

Les projets se terminent, l'équipe passe à autre chose, et ce qui a mal tourné reste dans les têtes. En 2015, le Project Management Institute a demandé dans son étude Pulse of the Profession avec quelle efficacité les organisations transmettent le savoir d'un projet à l'autre. Seules 14 pour cent se sont jugées très efficaces. Les organisations au taux de réussite élevé disposaient deux fois plus souvent d'un processus formel : 75 contre 35 pour cent.

Trois enseignements de la recherche expliquent cet écart.

L'erreur de planification. Daniel Kahneman et Amos Tversky ont décrit en 1979 que les gens sous-estiment systématiquement la durée de leurs propres projets, même lorsqu'ils savent que des projets similaires ont pris plus de temps. Dans « Système 1 / Système 2 » (2011), Kahneman raconte un projet de manuel scolaire qu'il a lui-même mené : l'équipe tablait sur environ deux ans, des équipes comparables en avaient mis sept à dix, beaucoup n'avaient jamais terminé. Au final, il a fallu huit ans. Douglas Hofstadter a formulé le phénomène en loi en 1979 dans « Gödel, Escher, Bach » : « Il faut toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter. » Pourquoi les gens décident comme ils décident dans un projet, notre panorama des théories psychologiques pour les chefs de projet le traite également.

Vue de l'intérieur et vue de l'extérieur. Kahneman distingue deux façons d'estimer. La vue de l'intérieur considère son propre projet avec ses plans et ses hypothèses. La vue de l'extérieur demande comment des projets comparables se sont déroulés, et intègre ainsi les perturbations que personne ne connaît à l'avance. Bent Flyvbjerg en a tiré le Reference Class Forecasting : on estime un nouveau projet à partir des résultats réels d'une classe de projets similaires. Sa base de données couvre plus de 16 000 projets ; selon « How Big Things Get Done » (2023), seuls 8,5 pour cent d'entre eux ont tenu à la fois le budget et le calendrier.

Savoir tacite et savoir explicite. Ikujiro Nonaka et Hirotaka Takeuchi décrivent dans « The Knowledge-Creating Company » (1995) comment les organisations apprennent : en transformant le savoir que les personnes possèdent, mais formulent rarement, en savoir documenté. La phrase « Lefèvre livre toujours en retard » vit dans la tête d'un conducteur de travaux. « Huit à douze jours ouvrés de retard dans six projets sur six », la nouvelle collègue peut aussi s'en servir.

Un planning terminé est donc une classe de référence à l'état brut. Les valeurs réelles fournissent la vue de l'extérieur, les pièces jointes de risque et de problème le savoir documenté. Il manque l'analyse sur plusieurs projets.

Merlin Project et le serveur MCP

Merlin Project enregistre pour chaque tâche des valeurs planifiées, prévues et réelles. S'y ajoutent des pièces jointes sur les tâches, affectations et ressources, dont Risque, Problème et Information. Comment saisir les valeurs réelles en cours de projet, la série Enregistrer l'avancement réel le montre ; le chapitre Comparaison plan/réel explique les bases.

Le serveur MCP de Merlin Project donne à une IA comme Claude un accès en lecture à ces données. Vous l'activez projet par projet via le bouton « Outils d’IA » dans la barre d'outils ; la documentation MCP décrit la configuration. Pour la base de connaissances, deux propriétés comptent. Le serveur travaille avec tous les documents ouverts et partagés, l'IA les analyse projet par projet. Pour une archive, vous ouvrez donc les projets terminés qui entrent dans l'analyse. Et le serveur ne fait que lire : aucun planning ne change, vous reportez vous-même les enseignements dans le projet suivant. Ce qu'il advient de vos données, l'article sur la souveraineté numérique et la protection des données l'explique.

Un planning terminé contient neuf sources d'apprentissage. Les sections numérotées après le calculateur les traitent dans cet ordre.

Calculateur : ce que votre archive fournit déjà

Les analyses que votre archive permet aujourd'hui dépendent de cinq habitudes dans Merlin Project. Le calculateur les passe en revue et montre quelles analyses sont déjà possibles, lesquelles manquent encore et quelle étape en ouvre le plus. Chaque ligne mène à la section correspondante.

1. Comparaison prévu-réel : le facteur d'estimation par type de tâche

La comparaison prévu/réel sert au pilotage en cours de projet. Sur plusieurs projets, elle devient un outil d'apprentissage : la durée réelle divisée par la durée planifiée donne un facteur. S'il dépasse 1 pour un type de tâche dans chaque projet, l'erreur d'estimation est systématique. C'est la vue de l'extérieur de Kahneman, appliquée à des tâches individuelles. Avec ce facteur, vous corrigez les nouvelles estimations avant qu'elles n'entrent dans l'offre. La condition préalable est la comparabilité : si une tâche s'appelle une fois « EXE Gros œuvre » et une autre fois « EXE GO », aucune analyse ne fait le lien.

Dans Merlin Project, affichez dans la vue Plan les colonnes Travail planifié, Travail réel, Fin planifiée et Fin réelle. Des noms de tâches uniformes ou un champ personnalisé comme « Type de tâche » ou « Corps d'état », que vous créez dans l'inspecteur sous Champs, assurent la comparabilité. Enregistrez-le dans un modèle de projet ou dans la bibliothèque, et chaque nouveau projet le porte dès le départ. Via le serveur MCP, l'IA lit les valeurs planifiées et réelles de chaque tâche.

Dans notre archive d'exemple

L'autorisation auprès du service urbanisme de la ville a duré en moyenne deux fois plus longtemps que prévu, auprès de la préfecture exactement comme prévu. Avec une valeur forfaitaire pour « Autorisation », l'agence aurait mal estimé les deux administrations. Les deux sections suivantes traitent ces facteurs externes. Le facteur de votre propre travail mérite l'attention : les plans d'exécution ont duré dans chacun des dix projets terminés 13 à 15 pour cent plus longtemps que prévu. En ajoutant 1,15, vous planifiez donc avec le cas normal mesuré.

Comparaison plan/réel dans Merlin Project

La vue Répartition du travail avec les colonnes Durée planifiée et Durée prévue. Pour la livraison des fenêtres, 3 semaines étaient prévues, Lefèvre a mis 1,35 mois. La partie inférieure affiche le risque de cette tâche avec son retour d'expérience.

Le prompt à tester vous-même

J'ai ouvert dix projets terminés dans Merlin Project et je les ai partagés
avec les outils d'IA. Lis dans chaque projet toutes les tâches terminées
avec leur durée planifiée et leur durée réelle. Regroupe les tâches de même
nom sur l'ensemble des projets et calcule pour chaque type de tâche le
facteur durée réelle divisée par durée planifiée. Montre-moi un tableau
avec le nombre de projets, le facteur moyen, la valeur la plus faible et la
plus élevée. Trie par facteur moyen, les plus grands écarts en haut.

2. Fournisseurs et partenaires : le respect des délais en chiffres

Les dates des fournisseurs et partenaires sont des dépendances externes : elles échappent à votre influence, et chaque retard touche tous les successeurs. Le planning contient le délai promis, la base de connaissances ajoute le délai tenu. Vous choisissez ainsi fournisseurs et sous-traitants selon leur respect des délais mesuré et prévoyez pour chacun le délai de livraison dont il a réellement besoin. Faites attention au dénominateur : deux retards sur deux commandes pèsent plus lourd que deux sur vingt, et seul le nombre de commandes transforme une impression en taux. Comment piloter les fournisseurs dès le départ, l'article sur la gestion des approvisionnements le décrit.

Dans Merlin Project, créez les entreprises externes comme ressources ou saisissez le nom de l'entreprise dans un champ « Fournisseur » ; chaque tâche de livraison se rattache ainsi à une entreprise. Les tâches en retard reçoivent une pièce jointe de type Problème avec catégorie, type et courte description. La vue Pièces jointes liste tous les problèmes d'un projet. La base de connaissances a besoin des deux : le retard mesuré issu des valeurs réelles et la cause issue de la pièce jointe Problème.

Dans notre archive d'exemple

Menuiseries Lefèvre a livré en retard sur chacune de ses six commandes. Dans les trois premiers projets, cela ne figurait dans le planning que comme pièce jointe Problème, comme un désagrément isolé. Seule la comparaison révèle le schéma : huit à douze jours ouvrés après la date promise, pendant que le bâtiment restait ouvert et que plâtrerie et chape attendaient. L'agence est passée à Fenêtres Garnier, qui a livré au plus un jour après la date promise. Pour les structures, même scénario : le Bureau d'études Girard a livré deux fois avec six jours ouvrés de retard, Bernard est resté dans les délais sur dix commandes.

Une pièce jointe Problème dans Merlin Project

La faillite du plâtrier ne figurait dans aucun registre. Enregistrée comme problème avec catégorie, type et état, elle reste toutefois exploitable, et l'IA la retrouve en cherchant des défaillances récurrentes.

Le prompt à tester vous-même

Lis dans tous les projets partagés les tâches auxquelles participent des
entreprises externes, avec leur fin planifiée et leur fin réelle. Calcule
pour chaque entreprise le nombre de commandes, le retard moyen en jours
ouvrés et le retard maximal. Ajoute les pièces jointes Problème de ces
tâches et résume les causes indiquées. Quelle entreprise est peu fiable
sur plusieurs projets, et sur quelle base de données repose ce constat ?

3. Administrations et délais : la durée par interlocuteur

Les procédures administratives interviennent tôt dans le projet, souvent sur le chemin critique, et chaque jour de retard décale tout ce qui suit. Les textes de loi et notices indiquent des délais réglementaires qui ont peu à voir avec le temps de traitement réel. Planifier le délai réglementaire, c'est estimer depuis la vue de l'intérieur. Si vous planifiez plutôt autorisations, contrôles et délais de consultation avec le temps de traitement mesuré de l'administration compétente, vous évitez le retard majeur le plus fréquent en début de projet.

Dans Merlin Project, modélisez autorisations et délais comme des tâches distinctes. Les temps d'attente pendant lesquels seule l'administration travaille se créent avec une durée et sans affectation ; notez l'administration compétente dans un champ « Administration ». Une fois la tâche terminée, saisissez la fin réelle, même sans travail sur la tâche ; sinon la valeur réelle la plus importante du projet manque. Quelles phases et quels délais marquent un projet d'architecture, le guide de la gestion de projet en architecture le résume.

Dans notre archive d'exemple

Le service urbanisme de la ville a mis 59 à 72 jours ouvrés dans cinq projets, alors que 30 à 40 étaient prévus. La préfecture a tenu exactement les 30 prévus dans quatre projets. Avec une valeur commune aux deux administrations, une agence se trompe de plusieurs semaines pour la ville ou gaspille de la réserve pour la préfecture. Conclusion : prévoir une durée par administration. Les marchés publics suivent la même logique. Un référé précontractuel a coûté 20 jours ouvrés à la crèche Soleil ; pour la crèche Arc-en-ciel, l'agence a validé la grille d'analyse des offres en amont avec l'acheteur public, et aucun recours n'a été déposé.

Durée d'autorisation dans le planning

Pour la Résidence du Parc, l'agence avait planifié 2 mois pour la procédure d'autorisation, le service d'urbanisme en a mis 3,6. Le risque en dessous enregistre 32 jours de retard, et l'information de clôture fixe la valeur pour le prochain projet : 65 JO.

Le prompt à tester vous-même

Cherche dans tous les projets partagés les tâches liées aux autorisations,
aux contrôles et aux délais de consultation. Indique pour chaque tâche le
projet, l'administration compétente d'après la description du projet, la
durée planifiée et la durée réelle. Regroupe par administration et donne
pour chacune la durée la plus courte, typique et la plus longue. Quelle
valeur devrais-je prévoir pour un nouveau projet auprès de la même
administration ?

4. Fourchettes : l'estimation à trois points à partir de données réelles

L'estimation à trois points décrit une tâche par trois valeurs : optimiste (O), probable (M) et pessimiste (P). La formule PERT (O + 4M + P) / 6 les condense en une valeur attendue et pondère M quatre fois ; notre guide des diagrammes PERT en explique le contexte. Le plus souvent, l'équipe devine les trois valeurs. Avec une base de connaissances, vous les mesurez : O comme valeur observée la plus courte, M comme la plus fréquente, P comme la plus longue. Les tâches récurrentes reçoivent ainsi une fourchette fiable au lieu d'un chiffre qui n'est juste qu'en moyenne. Comment en tirer une distribution, le guide de la simulation de Monte-Carlo le montre.

Merlin Project enregistre pour chaque tâche une durée planifiée et une valeur réelle ; il n'existe pas d'estimation à trois points native. Créez deux champs personnalisés pour O et P et renseignez-les dans le modèle avec les valeurs de la base de connaissances ; la durée planifiée reste M. L'IA lit les trois valeurs via le serveur MCP et simule avec elles, comme le montre l'article Simulation de Monte-Carlo dans Merlin Project.

Dans notre archive d'exemple

Moyenne et PERT aboutissent à environ 66 jours ouvrés ; depuis 2024, l'agence prévoit 65. Une valeur unique tait toutefois l'ampleur des variations d'une tâche. Au service urbanisme de la ville, 13 jours ouvrés séparent la procédure la plus courte de la plus longue, à la préfecture pas un seul. Seul le premier cas a besoin de réserve. La fourchette de 59 à 72 sert en outre d'entrée à une simulation de Monte-Carlo ; avec des valeurs mesurées, elle remplace l'hypothèse forfaitaire « durée prévue plus ou moins 20 pour cent ».

Le prompt à tester vous-même

Pour chaque type de tâche présent dans au moins trois projets partagés,
calcule une estimation à trois points à partir des durées réelles : O
comme valeur la plus courte, M comme la plus fréquente et P comme la plus
longue. Indique en plus la valeur attendue PERT (O + 4M + P) / 6. Signale
les types de tâches présents dans moins de cinq projets comme base de
données incertaine.

5. Marges : la réserve aux endroits dispersés

Une marge protège une échéance contre l'incertitude. Répartie forfaitairement, par exemple dix pour cent par tâche, elle atterrit sur les tâches stables et manque sur celles qui varient. S'y ajoute un effet comportemental. Cyril Northcote Parkinson écrivait en 1955 dans The Economist : « Le travail s'étale de façon à occuper le temps disponible pour son achèvement. » Qui donne de la réserve à chaque tâche la voit le plus souvent consommée. Eliyahu Goldratt en a tiré la conséquence dans « Critical Chain » (1997) : retirer la réserve des tâches et la regrouper devant les échéances critiques. La base de connaissances indique la taille de cette marge et son emplacement : derrière les tâches très dispersées du chemin critique. Avec la même réserve, vous tenez alors plus souvent vos échéances.

Dans Merlin Project, placez les marges regroupées comme tâches distinctes sans affectation devant le jalon qu'elles protègent, et nommez-les sans ambiguïté, par exemple « Marge autorisation ». En cours de projet, vous voyez alors combien de réserve est consommée. Là où le réseau dispose de lui-même de jeu, les colonnes Marge totale prévue et Marge libre prévue le montrent. Si la réserve ne suffit pas pour la date souhaitée, les techniques de l'article sur le fast tracking, le crashing et le contouring vous aident.

Dans notre archive d'exemple

Répartie forfaitairement, la réserve manque à l'autorisation, qui varie jusqu'à 13 jours ouvrés dans les données ; placée de façon ciblée, elle se trouve là où se trouve la dispersion. La taille d'une marge découle de la fourchette. Si une tâche se situe dans l'archive entre 59 et 72 jours ouvrés et que vous en prévoyez 66, il vous faut environ six jours de réserve derrière pour un bon respect des délais. Pour une tâche qui n'a jamais dévié de plus d'un jour sur dix projets, vous économisez la majoration. Une simulation de Monte-Carlo avec P80 ou P90 indique si la réserve suffit au total.

Là où le réseau n'a aucun jeu

La colonne Marge totale prévue affiche 0 jours pour la procédure d'autorisation. Comme toutes les tâches du chemin critique, elle n'a aucun jeu : chaque jour de retard décale la fin du projet. Laquelle a besoin d'une marge regroupée, seule la dispersion de l'archive le dit.

Le prompt à tester vous-même

Lis le planning du nouveau projet dans le document actuel. Compare chaque
tâche du chemin critique avec les fourchettes de notre base de
connaissances, que je te fournis sous forme de fichier. Propose derrière
quelles tâches placer une marge regroupée et quelle taille elle doit avoir
pour que la date de fin tienne avec une probabilité d'environ 80 pour
cent. Cite les tâches dont la durée planifiée contient déjà de la réserve.

6. Saison et contexte : les facteurs saisonniers

Certains écarts dépendent du moment où se déroule une tâche. Dans le bâtiment, le gel et la pluie freinent le gros œuvre, et la chape sèche plus lentement en hiver ; dans le développement logiciel, ce sont les périodes de congés ou les clôtures trimestrielles chez le client. Ces influences touchent plusieurs tâches à la fois, ce que la théorie de Monte-Carlo appelle corrélation. Un facteur saisonnier les intègre de la manière la plus simple dans l'estimation : vous identifiez les tâches qui durent plus longtemps à certaines saisons et les décalez ou prévoyez la majoration.

Grâce au début réel, l'IA attribue chaque tâche de Merlin Project à une saison. Modélisez les temps de séchage et d'attente dépendant de la météo comme tâches distinctes sans affectation, pour que leur durée reste mesurable. Saisissez les congés d'entreprise et jours fériés dans les réglages du projet sous Calendrier ; sinon, les semaines de congés apparaissent comme retard dans les statistiques.

Dans notre archive d'exemple

L'hiver a coûté du temps à chaque gros œuvre : 15 pour cent chez l'entreprise de gros œuvre fiable, 48 chez Vasseur. Vasseur construisait déjà en été un quart plus lentement que prévu. Dans un projet, le gros œuvre a été arrêté 15 jours ouvrés à cause du gel. La règle qui en découle : ne pas planifier le gros œuvre entre décembre et février, ou intégrer les travaux d'hiver avec facteur et coûts. Le schéma Vasseur ne figurait dans aucun registre des risques. Il ne devient visible que lorsque quelqu'un regroupe les valeurs réelles par entreprise et par mois.

Un risque hivernal au gros œuvre

Le plancher du rez-de-chaussée est tombé en décembre. Le risque Gel et intempéries au gros œuvre est survenu, avec 7 jours de retard et 8 400 euros de coûts. Avec ses dates, ses valeurs réelles et son risque, la tâche fournit tout ce dont un facteur saisonnier a besoin.

Le prompt à tester vous-même

Regroupe toutes les tâches de gros œuvre et de séchage terminées des
projets partagés par mois de début réel et par entreprise exécutante.
Calcule pour chaque groupe le facteur durée réelle sur durée planifiée.
Y a-t-il des mois ou des entreprises pour lesquels les mêmes tâches durent
nettement plus longtemps ? Quels facteurs devrais-je prévoir pour un gros
œuvre en janvier ?

7. Effort de conception et coûts : ce que coûte votre propre prestation

Les coûts dérivent à deux endroits : pour les prestations externes par avenants et hausses de prix, et pour votre propre travail. Beaucoup négligent la seconde source, parce qu'elle ne figure sur aucune facture. Avec un honoraire forfaitaire, l'agence supporte elle-même chaque heure sous-estimée ; quelle forme de contrat répartit quel risque, l'article sur le prix forfaitaire, la régie et le remboursement des coûts l'explique. En cours de projet, l'analyse de la valeur acquise montre l'écart, l'indice de performance des coûts CPI la performance par euro dépensé. Sur des projets terminés, il en résulte un facteur de chiffrage, et vos offres et honoraires reflètent l'effort dont votre équipe a réellement besoin.

Avec un taux horaire par ressource, Merlin Project calcule à partir du travail planifié et réel les coûts planifiés et réels ; le chapitre Coûts montre comment saisir les coûts. Les indicateurs de l'analyse de la valeur acquise (PV, EV, AC, CPI, SPI) se rapportent à la date d'état définie dans les réglages du projet. Pour une vue transversale de la charge, tous les projets partagent un pool de ressources. Le serveur MCP fournit en outre des valeurs phasées dans le temps pour les coûts, le travail et la valeur acquise, c'est-à-dire leur évolution sur des semaines ou des mois.

Dans notre archive d'exemple

L'agence a sous-estimé ses plans d'exécution dans chaque projet, de 15 pour cent dans le cas normal. Sur dix projets, cela représente 118 jours ouvrés, soit 86 848 euros pour un taux horaire de 92 euros, qui ne figuraient dans aucun honoraire. Les mêmes données contiennent un second schéma : lorsque trois projets se trouvaient simultanément en plans d'exécution, le facteur montait à 1,35 voire 1,37, et la direction de projet signalait une surcharge. Pour le chiffrage, cela signifie 15 pour cent de majoration sur votre propre conception et au plus deux projets en parallèle dans cette phase. Côté coûts externes, la hausse des coûts de construction en 2021 et 2022 ressort : elle a touché chaque projet démarré ces années-là, avec 20 000 à 137 800 euros au-dessus de l'estimation.

L'effort de conception en comparaison plan/réel

Les colonnes affichent le travail et les coûts planifiés et réels. Dans la Résidence du Parc, la phase 5 Plans d'exécution a coûté 69 920 euros au lieu de 51 520. Le problème en dessous en donne la raison : la direction de projet était surchargée.

Le prompt à tester vous-même

Lis dans tous les projets partagés le travail planifié et réel ainsi que
les coûts planifiés et réels par phase. Calcule pour chaque phase le
facteur réel sur planifié et le surcoût en euros. Vérifie en outre, à
partir des dates réelles, combien de projets se trouvaient simultanément
en plans d'exécution, et si le facteur augmente dans ce cas.

8. Risques et problèmes : calibrer les probabilités

Un registre des risques contient des estimations : quelle est la probabilité qu'un risque survienne, et combien coûte-t-il alors ? À la fin du projet, on sait ce qui s'est passé. La comparaison des deux s'appelle la calibration. Si une équipe bien calibrée évalue des risques à 30 pour cent, environ trois sur dix surviennent. Si le taux s'en écarte fortement, le registre dirige l'attention aux mauvais endroits. Avec des valeurs calibrées, le prochain registre démarre avec les risques qui surviennent réellement chez vous. Les problèmes complètent le tableau avec les événements que personne n'attendait comme risque.

Dans Merlin Project, le type de pièce jointe Risque contient, outre la probabilité et l'impact, quatre champs pour l'issue : Survenu, Coûts, Retard et Retour d'expérience. Coûts et retard servent à documenter ; Merlin ne les intègre ni au planning ni au budget. Renseignez ces champs au plus tard à la clôture du projet, sinon le registre reste une liste de craintes. Saisissez les perturbations imprévues comme Problème. Le chapitre Gestion des risques explique les bases, le guide de la gestion des risques avec Merlin Project le pilotage en cours de projet.

Dans notre archive d'exemple

Le registre mûrit avec le temps. Les quatre premiers projets contiennent sept risques au total ; le retard des fenêtres n'y figurait que comme problème. À partir du cinquième projet, l'agence a repris les leçons des projets précédents comme risques avec mesures. La calibration a apporté deux corrections. Le risque lié au sol figurait à 30 pour cent dans le registre de six constructions neuves et est survenu une fois, sur un terrain avec des constructions existantes ; pour les zones d'urbanisation neuves, l'agence l'a abaissé à 15 pour cent. Un changement de fournisseur a réglé le retard de livraison chez Lefèvre, survenu sur les trois commandes. Un troisième schéma, l'entreprise de gros œuvre lente en hiver, n'apparaissait dans aucun registre. Une base de connaissances a donc besoin des deux sources : risques documentés et simples écarts dans les valeurs réelles.

Un risque clôturé

Retard de livraison fenêtres, survenu avec 12 jours de retard et 10 800 euros de coûts. Seuls les champs de clôture, ici en colonnes du registre, transforment une crainte en point de données pour la calibration.

Le prompt à tester vous-même

Lis dans tous les projets partagés les pièces jointes Risque avec titre,
probabilité, Survenu, Coûts, Retard et Retour d'expérience, ainsi que
toutes les pièces jointes Problème. Regroupe les risques similaires sur
l'ensemble des projets. Compare pour chaque risque la probabilité estimée
avec le taux observé. Liste en outre les problèmes survenus plusieurs fois
sans jamais figurer comme risque dans un registre. Établis à partir de là
un registre initial pour un nouveau projet avec probabilité proposée,
impact typique et mesure éprouvée.

9. Retours d'expérience : des règles avec domaine de validité

Les retours d'expérience fournissent la justification des chiffres : pourquoi quelque chose a pris plus de temps et ce qui aide la fois suivante. Leur valeur dépend de deux choses. La première est l'attitude lors de l'entretien de clôture. Norman Kerth a formulé en 2001 la « Prime Directive » de la rétrospective : « Quoi que nous découvrions, nous comprenons et croyons sincèrement que chacun a fait du mieux qu'il pouvait, compte tenu de ce qu'il savait alors, de ses compétences et capacités, des ressources disponibles et de la situation du moment. » Qui cherche des coupables n'obtient pas de réponses honnêtes. La seconde est le domaine de validité : une leçon tirée d'une rénovation dans l'ancien ne vaut pas automatiquement pour une construction neuve, et sans indication de ce à quoi elle s'applique, elle reste une anecdote. Avec un domaine de validité, même les collègues qui n'y étaient pas retrouvent la leçon. La clôture du projet en décrit le cadre formel.

Dans Merlin Project, attachez au jalon « Clôture du projet » une pièce jointe de type Information contenant les retours d'expérience : ce qui a mal tourné, ce qui a fonctionné et pour quel type de projet la leçon vaut. Les leçons portant sur des risques individuels vont dans leur champ Retour d'expérience, où elles restent liées à la fréquence, aux coûts et au retard. Créez un type « Retours d'expérience » propre aux informations dans les réglages du projet sous Listes de valeurs.

Dans notre archive d'exemple

Deux rénovations dans l'ancien montrent l'effet d'une leçon avec domaine de validité. Dans l'immeuble haussmannien, les artisans ont trouvé de l'amiante lors du curage : 22 jours ouvrés d'arrêt de chantier, 38 000 euros d'avenant. La leçon : « Diagnostic des polluants avant la consultation, valable pour toute rénovation dans l'existant. » Pour la maison à colombages suivante, l'agence a fait réaliser le diagnostic en amont ; le désamiantage figurait ainsi déjà au DPGF.

Avec les demandes particulières des maîtres d'ouvrage privés, même scénario. Les maisons jumelées des Vignes ont perdu 15 jours ouvrés et 37 500 euros à cause de modifications du second œuvre ; une maison individuelle ultérieure a donc reçu une date butoir pour le choix des finitions avant le début du second œuvre.

Retours d'expérience à la clôture du projet

Une pièce jointe Information sur le jalon Clôture du projet consigne ce qui a mal tourné et ce qui a fonctionné. Via le serveur MCP, l'IA la lit avec les valeurs réelles.

Le prompt à tester vous-même

Lis les pièces jointes Information du jalon « Clôture du projet » et le
champ Retour d'expérience de tous les risques des projets partagés.
Formule à partir de là des règles transposables. Indique pour chaque règle
à quel type de projet, quelle phase ou quel corps d'état elle s'applique,
dans combien de projets elle est attestée et sur quels projets elle
s'appuie. Laisse de côté les cas isolés survenus une seule fois et sans
cause indiquée.

De l'archive à la base de connaissances

Les neuf analyses forment la base de connaissances. Pour que l'équipe l'utilise, elle a besoin d'une forme fixe qui s'enrichit après chaque projet. Un projet de documentation en cinq chapitres, que l'IA alimente à partir des projets Merlin, a fait ses preuves :

Base-de-connaissances-projet/
├── index.adoc                 Objectif, état des données, utilisation
├── 1-projets/                 une fiche par projet terminé
├── 2-indicateurs/             facteurs d'estimation, fourchettes, coûts
├── 3-risques-et-lecons/       catalogue des risques, retours d'expérience, registre initial
├── 4-modeles/                 prompts et checklists
└── 5-methodologie/            base de données, règles de mise à jour, glossaire

La fiche de chaque projet consigne le type de projet, la période, les délais et coûts en comparaison prévu-réel, ainsi que les cinq plus grands écarts, les risques survenus et les retours d'expérience. L'IA calcule les chapitres 2 et 3 à partir de toutes les fiches, et chaque valeur renvoie aux projets dont elle provient. Sous forme de fichiers AsciiDoc, adoc Studio exporte les chapitres en site web dont la navigation découle des dossiers et fichiers ; le modèle de projet pour la documentation offre une structure prête à adapter. Comme la base de connaissances contient des noms de clients, des coûts et des délais, sa place est sur un serveur protégé.

Après chaque projet terminé, une fiche s'ajoute, l'IA recalcule les chapitres 2 et 3, et vous exportez à nouveau le site web.

Ce que vous devriez tenir à jour dès aujourd'hui

Cinq habitudes décident si votre archive montrera dans un an des schémas ou des lacunes. Le calculateur montre où vous en êtes aujourd'hui.

1. Saisir les valeurs réelles sans attendre : début réel, fin réelle et travail réel pour chaque tâche terminée, y compris les temps d'attente et les autorisations.
2. Classer les tâches, le plus simplement via un champ pour le type de tâche ou des tags dans un modèle de projet commun. Des noms de tâches fixes issus du modèle font le même travail, tant que personne ne les modifie.
3. Rattacher les partenaires externes, comme ressource ou champ, pour pouvoir mesurer leur respect des délais.
4. Clôturer les risques avec Survenu, Coûts, Retard et Retour d'expérience, au plus tard à la clôture du projet.
5. Retours d'expérience avec domaine de validité comme pièce jointe Information sur le jalon « Clôture du projet ».

Limites de l'analyse

Une base de connaissances fournit des valeurs d'expérience qui gagnent en précision à chaque projet. Quatre limites en font partie.

• Petits échantillons. Deux livraisons en retard sur deux commandes sont un indice. Demandez à l'IA d'indiquer le nombre de projets pour chaque valeur, et traitez les valeurs issues de moins de cinq projets comme provisoires.
• Corrélation sans cause. Si l'entreprise de gros œuvre était plus lente en hiver à cause de la météo, de sa charge ou des deux, les chiffres seuls ne le disent pas. La justification figure dans les retours d'expérience.
• Conditions modifiées. Une nouvelle équipe, une nouvelle procédure au service urbanisme ou un autre marché déprécient les anciennes valeurs. Datez chaque valeur et pondérez davantage les projets récents.
• Lecture seule. Le serveur MCP de Merlin Project ne fait actuellement que lire. Vous reportez vous-même facteurs, marges et registre initial dans le nouveau planning. Les clients cloud comme Claude envoient les données de planning interrogées au fournisseur ; un modèle local les garde sur votre Mac.

La prochaine étape s'appuie sur cette base de connaissances. Avec le registre initial du chapitre 3 et les fourchettes du chapitre 2, vous pilotez les risques du projet en cours ; comment cela fonctionne dans Merlin Project, le guide de la gestion des risques avec Merlin Project et l'IA le montre.

Si vous avez des questions sur cet article de blog ou si vous souhaitez en discuter, nous attendons avec impatience votre contribution dans notre forum.