La certitude d'exécution pour des programmes technologiques complexes et à fort enjeu.

La gestion de projet à l'ère de l'IA

La profession a toujours réuni deux fonctions distinctes sous un même intitulé. La première est administrative : assembler les plannings, consolider l'avancement, rapprocher le réalisé du référentiel, mettre en forme le dossier de pilotage. La seconde est judiciaire : décider de ce que signifient les éléments, choisir quel témoignage créditer, déterminer quel risque mérite un budget, et savoir quand dire à un dirigeant une vérité qu'il n'a pas demandée. La fonction administrative produisait les artefacts ; la fonction judiciaire produisait la valeur. Pendant des décennies, les deux furent liées, car seul un humain pouvait assurer l'une ou l'autre.

Les grands modèles de langage et l'analytique prédictive les ont désormais dissociées. La génération de plannings, la synthèse d'avancement, la détection d'anomalies dans les courbes de consommation et la première rédaction des risques deviennent des tâches machine — exécutées plus vite, plus régulièrement, et sans le biais d'optimisme que les chaînes de reporting humaines introduisent. Dans ma propre mise en œuvre d'automatisation agentique au sein d'opérations de crédit, des systèmes auto-apprenants ont atteint 87 % de précision sur des processus exigeant auparavant une revue manuelle. Rien ne justifie, en principe, que le bureau de projet échappe à la même économie.

Le résidu judiciaire

Ce qui demeure est instructif. Un modèle peut signaler que les tests d'intégration consomment la marge à un rythme insoutenable ; il ne peut décider si le responsable des tests se ménage des réserves, si la réassurance du fournisseur est crédible, ou si l'appétence du sponsor pour un report de date a discrètement évolué depuis le dernier conseil. Ce sont là des problèmes de témoignage, d'incitation et de réalité politique — la matière du jugement, non du calcul. Les domaines de connaissance du PMBOK demeurent une taxonomie saine ; ce qui change, c'est que l'instrumentation de chaque domaine s'automatise quand son arbitrage, lui, ne s'automatise pas.

La gestion des risques illustre au mieux ce déplacement. La modélisation quantitative de l'exposition, l'analyse de planning par Monte-Carlo et la reconnaissance de motifs sur l'historique des programmes sont des tâches où la machine surpasse déjà le PMO médian. Mais l'appétence au risque n'est pas un jeu de données ; c'est un compromis négocié entre des parties prenantes inégalement exposées. Le registre des risques de la décennie à venir sera rédigé par la machine et possédé par l'humain — et les programmes qui confondront rédaction et possession découvriront la différence au pire moment.

Conséquences pour la profession

Trois s'imposent. D'abord, la voie d'entrée qui formait les juniors par la production d'artefacts s'érode ; la profession doit construire des apprentissages délibérés du jugement pour la remplacer. Ensuite, la maîtrise des méthodes — PMP, SAFe, Lean Six Sigma — compte davantage, et non moins, car le praticien doit désormais auditer la production de la machine à l'aune d'un modèle mental discipliné plutôt que produire lui-même. Enfin, la compétence différenciante devient ce qu'on pourrait nommer la supervision épistémique : savoir quand la machine se trompe avec assurance. L'ère de l'IA ne met pas le chef de projet à la retraite. Elle met à la retraite le chef de projet dont la valeur était administrative.

Gouverner les systèmes agentiques : une perspective programme

La gouvernance informatique classique suppose que le comportement du logiciel est spécifié avant le déploiement et vérifié contre cette spécification. La couverture de tests, la recette et la gestion des changements reposent sur cette hypothèse. Les systèmes agentiques la violent par conception : leur comportement se façonne par apprentissage après le déploiement, si bien que l'artefact gouverné à la mise en production n'est pas celui que l'on exploite six mois plus tard. Traiter cela par la gestion de versions conventionnelle est une erreur de catégorie — que j'ai vu des organisations commettre avec une diligence sincère et de piètres résultats.

Délégation, et non déploiement

Le cadre le plus fécond, d'expérience, est celui de la délégation. Quand une banque habilite un fondé de pouvoir junior à approuver des crédits sous un seuil, elle ne vérifie pas d'avance chacune de ses décisions futures. Elle borne l'autorité, surveille les exceptions, échantillonne le courant, et étend ou restreint le mandat à mesure que les preuves s'accumulent. Dans le programme d'automatisation du crédit que j'ai dirigé, ce cadre s'est transposé directement : les processus agentiques ont débuté avec une autorité étroite et une revue humaine de chaque sortie ; à mesure que la précision mesurée se stabilisait — à 87 % in fine —, la revue est passée de l'universel à l'échantillonnage pondéré par le risque, avec des bornes dures qu'aucun apprentissage ne pouvait desserrer sans ré-autorisation humaine.

La gouvernance de programme doit donc enrichir sa panoplie de trois instruments. D'abord, une matrice d'autorité pour le système lui-même — un RACI où l'agent est une ligne, avec des déclencheurs d'escalade explicites. Ensuite, la surveillance de la dérive comme chantier permanent et non comme activité post-incident : le registre des risques doit traiter la dégradation du modèle comme une dépendance vivante, revue au même rythme que le budget et le planning. Enfin, la réversibilité comme exigence de conception — l'équivalent opérationnel d'un plan de contingence, répété et non simplement documenté, par lequel le processus revient à l'exécution humaine sans interruption de service.

La nouvelle question du comité de pilotage

Les instances exécutives ont l'habitude de demander si un système fonctionne. Pour les systèmes agentiques, la question de gouvernement est subtilement autre : dans quelles conditions cesse-t-il de fonctionner, et en combien de temps le saurions-nous ? Un comité de pilotage qui ne peut y répondre n'a pas gouverné le système ; il l'a seulement acheté. Les disciplines requises n'ont rien d'exotique — ce sont la gestion des risques, les jalons et le suivi des bénéfices, appliqués avec honnêteté intellectuelle à une technologie qui change sous leurs pieds. Les cadres tiennent. Ce qui doit changer, c'est l'hypothèse, confortable et obsolète, selon laquelle le déploiement clôt la question du comportement au lieu de l'ouvrir.

De la complexité émergente dans les programmes de grande échelle

Partons d'une distinction empruntée à la théorie des systèmes : le compliqué et le complexe. Un système compliqué — un réacteur d'avion, une migration de paie — comporte de nombreuses pièces dont les interactions sont connaissables et stables ; il cède à la décomposition, à la planification, à l'expertise. Un système complexe engendre des comportements inédits : le tout fait des choses qu'aucun inventaire des parties ne prédisait. L'essentiel de la doctrine — de l'organigramme des tâches à la valeur acquise — est une ingénierie du compliqué. Or les grands programmes, passé une certaine échelle, sont complexes — et la doctrine n'annonce pas le franchissement du seuil.

Par où la complexité entre

Trois mécanismes reviennent dans les programmes que j'ai dirigés ou redressés. Le premier est la prolifération des interfaces : le nombre de relations entre chantiers croît au carré de leur nombre, et chaque interface est un lieu où les hypothèses divergent en silence. Un programme de cinq projets compte dix coutures ; un programme de vingt en compte cent quatre-vingt-dix. Aucun atelier de risques ne les énumère toutes, et les échecs décisifs logent dans les coutures que personne ne possédait. Le deuxième est le délai de rétroaction : à grande échelle, la conséquence d'une décision émerge des mois plus tard et plusieurs strates organisationnelles plus loin, quand sa cause est devenue inattribuable et sa correction politiquement coûteuse. Le troisième est l'agrégation des rationalités locales — chaque chantier optimisant son jalon, chaque fournisseur protégeant sa marge, chaque région suivant son régulateur — en des résultats que personne n'a choisis. Rien de tout cela n'est un défaut de compétence. C'est ce que fait l'échelle.

Gouverner pour l'émergence

La réponse pratique n'est pas d'abandonner le contrôle classique, mais d'y ajouter ce qui lui manque. La cartographie des dépendances doit être un artefact vivant, avec des propriétaires nommés pour les coutures, non pour les seules cases. La cadence de reporting doit raccourcir délibérément la boucle de rétroaction — la fonction d'un rythme hebdomadaire n'est pas le confort bureaucratique mais la latence de correction d'erreur. Les réserves, de délai comme de budget, doivent être tenues au niveau du programme plutôt que distribuées aux chantiers, où la rationalité locale les consommera comme un dû. Et le processus de risques doit réserver une attention permanente aux inconnues inconnues : prémortems structurés, audits croisés d'hypothèses, et l'habitude cultivée de traiter les signaux faibles — une facture fournisseur qui glisse, une partie prenante devenue silencieuse — comme des données. Dans mes propres mandats de redressement, la blessure originelle n'était presque jamais le risque inscrit au registre. C'était l'interaction qu'aucun registre n'aurait pu contenir. L'humilité devant ce fait, institutionnalisée dans la gouvernance, sépare les programmes qui absorbent la surprise de ceux qu'elle détruit.

La culture comme infrastructure des grands programmes internationaux

Pour avoir livré des programmes en France, au Royaume-Uni, en Israël, en Afrique du Sud, en Inde, aux États-Unis et dans le Golfe — souvent tous réunis sur le même appel —, j'en suis venu à une conviction qui s'accorde mal avec la littérature méthodologique : le risque dominant des programmes internationaux est sémantique. Un statut « orange » est un signal routinier dans une culture de travail et un événement de carrière dans une autre. « Oui » peut signifier l'accord, la prise d'acte ou la courtoisie. Un silence en revue de conception peut signifier le consentement, le désaccord ou la déférence hiérarchique — et le directeur de programme qui ne sait pas les distinguer ne lit pas le programme, seulement sa paperasse.

L'interface interprétative

La recherche interculturelle — les dimensions de Hofstede, la cartographie culturelle de Meyer — fournit un vocabulaire utile : la distance hiérarchique détermine qui contredira un plan en public ; l'évitement de l'incertitude détermine si l'ambiguïté est tolérée ou escaladée ; les styles de communication séparent les cultures à contexte faible, où le sens loge dans les mots, des cultures à contexte fort, où il loge autour. Mais la tâche du praticien n'est pas la classification, c'est l'ingénierie. Chaque paire d'équipes d'un programme distribué constitue une interface interprétative, exactement aussi réelle qu'une API, et exactement aussi capable de violation silencieuse de contrat. Le programme qui cartographie ses interfaces techniques mais non ses interfaces interprétatives n'a cartographié que la moitié de sa surface de risque.

Traiter la culture comme une infrastructure implique des pratiques concrètes. La sémantique d'escalade doit être explicitée et enseignée, non supposée : ce que signifie l'orange, ce qu'il oblige, et ce qu'il coûte — rien — de le lever. Les artefacts doivent être conçus pour une lecture à contexte faible, car un programme distribué ne peut compter sur le contexte de couloir pour réparer l'ambiguïté ; c'est la raison sans éclat pour laquelle la documentation disciplinée, la clarté des RACI et les relevés de décision écrits comptent davantage dans les programmes internationaux que dans les équipes co-localisées. L'architecture des réunions doit compenser la distance hiérarchique : tours de table structurés, pré-lectures écrites, et canaux privés permettant au désaccord de remonter à coût supportable. Et le directeur de programme doit fonctionner comme une couche de traduction — ce qui exige l'humilité de tenir, en posture permanente, sa propre culture de travail pour un accent, non pour une norme.

Culture et dividende de gouvernance

La récompense de cette ingénierie n'est pas l'harmonie ; c'est la fidélité du signal. Les programmes échouent tard et cher quand la mauvaise nouvelle voyage lentement, et la mauvaise nouvelle voyage lentement précisément à travers les interfaces où l'interprétation est incertaine. Un programme à l'infrastructure culturelle saine entend la vérité plus tôt — et dans le delivery, le temps est la seule monnaie qu'on ne peut re-baseliner. La diversité, gouvernée avec ce sérieux, cesse d'être un risque à mitiger et devient ce que la recherche suggère depuis longtemps : un élargissement du répertoire de jugement du programme, et une couverture contre les angles morts de monoculture que les équipes homogènes prennent pour du consensus.

Quatre géographies du delivery : la gestion de projet en Inde, au Royaume-Uni, aux États-Unis et en Afrique

Une précaution s'impose d'emblée : les géographies ne sont pas des monolithes. « L'Afrique » compte cinquante-quatre pays ; la culture de delivery indienne diffère entre un éditeur de Bangalore et une banque de Mumbai ; et toute comparaison troque la nuance contre le motif. Ce qui suit relève de tendances observées dans des programmes que j'ai menés dans et pour ces marchés — des motifs institutionnels aux causes structurelles, non des caractères nationaux.

Filiations méthodologiques

La première divergence est généalogique. La pratique britannique descend de PRINCE2 et de la tradition des projets publics — centrée sur le processus, riche en documentation, avec une conception forte du business case comme constitution vivante du programme et de l'assurance comme fonction indépendante du delivery. La pratique américaine descend du PMI et de la lignée défense-aérospatiale du chemin critique et de la valeur acquise : la planification comme ingénierie, le chef de projet comme propriétaire investi, et une culture contractuelle où le périmètre s'arbitre autant qu'il se gère. La pratique indienne a grandi dans l'industrie du delivery offshore, et cela se voit de manière admirable : maturité des processus (la tradition CMMI), discipline des métriques, et une aisance inégalée à faire fonctionner de grandes organisations d'ingénierie distribuées — quoique l'histoire commerciale de l'asymétrie client-fournisseur puisse laisser un résidu de déférence à la table de gouvernance. Les programmes africains, dans mon expérience sud-africaine et panafricaine, sont souvent les plus pragmatiquement hybrides : des cadres formels hérités de la gouvernance britannique et des bailleurs multilatéraux, appliqués sous contrainte réelle de ressources — ce qui produit un talent distinctif d'adaptation et la capacité de sauter entièrement des étapes héritées, comme la révolution du mobile money l'a démontré au reste du monde.

Gouvernance et escalade

La posture de gouvernance suit la filiation. Le comité de pilotage britannique est procéduralement fort et poliment indirect ; le risque s'escalade tôt, mais s'énonce avec retenue. L'instance américaine est commercialement directe ; la mauvaise nouvelle voyage vite, parfois de façon adversariale, un œil sur le contrat. Les organisations de delivery indiennes escaladent méticuleusement dans leur propre hiérarchie mais peuvent hésiter à faire franchir au statut rouge la frontière du client — artefact structurel, là encore, de l'économie du modèle fournisseur plutôt que d'un déficit de franchise, et contre lequel un directeur de programme doit délibérément s'organiser. Dans plusieurs contextes africains, la hiérarchie et la relation précèdent le processus : le chemin d'escalade formel existe sur le papier, mais la résolution avance à la vitesse de la confiance — ce qui récompense les dirigeants qui investissent dans les relations avant d'en avoir besoin. Aucune de ces postures n'est fausse ; chacune échoue différemment quand on l'exporte sans examen.

Ce que chacune peut emprunter

Le bénéfice de la comparaison est pratique. De la pratique britannique : le business case vivant et l'assurance indépendante — des disciplines qui empêchent l'élan du delivery de distancer sa raison d'être. De la pratique américaine : l'analytique de planning, la propriété investie et la franchise sans sentimentalisme en comité. De la pratique indienne : une maturité de processus de grade industriel, l'hygiène des métriques et l'art opérationnel de coordonner des organisations distribuées de mille personnes. De la pratique africaine : l'innovation frugale, la gouvernance adaptative et l'humilité de concevoir pour la contrainte plutôt que de présumer l'abondance. Ma propre méthode est un composite délibéré des quatre — ce qui est, je crois, ce que quinze années à travers ces marchés doivent produire. La discipline universelle se révèle être l'aptitude à traduire entre les disciplines locales.

Des cathédrales aux lignes de code : l'évolution de la gestion de projet et les migrations de son langage

La pratique est ancienne ; la profession a à peine soixante-dix ans. Les maîtres d'œuvre de Gizeh et des chantiers de cathédrales géraient périmètre, main-d'œuvre, logistique et attentes du commanditaire sur des décennies — mais ils géraient par l'apprentissage et l'autorité, non par une méthode transmissible. La première codification vint avec la modernité industrielle : les diagrammes de Henry Gantt dans les années 1910, puis les grands programmes de défense et de chimie du milieu du siècle — la méthode du chemin critique de DuPont et le PERT de la marine américaine, conçu pour le programme de missiles Polaris à la fin des années 1950 — qui firent de la planification une mathématique. La fondation du PMI en 1969, la tradition du PMBOK qui suivit et la lignée britannique PRINCE donnèrent à la discipline ses institutions. Le contre-mouvement arriva en 2001, quand le Manifeste agile rejeta la planification prédictive au profit de l'itération empirique ; les décennies suivantes furent pour l'essentiel une négociation entre ces deux héritages — négociation que les cadres à l'échelle comme SAFe tentent, avec une élégance inégale, de formaliser.

L'adaptation à la physique de chaque industrie

Chaque industrie a plié la méthode à sa propre physique de l'irréversibilité. La construction et l'aérospatiale, où le changement tardif est ruineux, ont conservé le cœur prédictif : conception amont approfondie, contrôle de référentiel, valeur acquise. La pharmacie s'est organisée autour du stage-gate — structure née dans l'industrie chimique — parce que la science réglementaire veut que la connaissance arrive par expériences discrètes et coûteuses. Le logiciel, où le changement est bon marché et les exigences instables, a inversé entièrement le modèle : itérer, démontrer, adapter. Les services financiers, mon territoire d'origine, sont le grand hybrideur — un delivery agile enveloppé dans une gouvernance prédictive, parce que le régulateur exige une redevabilité prédictive là même où l'ingénierie prospère par l'empirisme. La leçon se généralise : la méthodologie n'est pas un credo mais une réponse au coût, propre à chaque industrie, d'avoir tort tard — et la première question diagnostique du praticien dans un secteur nouveau devrait être exactement celle-là : que coûte-t-il, ici, de changer d'avis tardivement ?

Les migrations du langage

Observez le vocabulaire, et vous verrez les industries s'instruire mutuellement. Le « scrum » est entré dans le logiciel depuis le rugby, via l'étude de Takeuchi et Nonaka (1986) sur les équipes manufacturières japonaises — une métaphore sportive, blanchie par la recherche industrielle, adoptée par les programmeurs. Le « lean » et le « kanban » viennent des ateliers de Toyota et gouvernent aujourd'hui aussi bien les flux logiciels que les opérations hospitalières. Le « waterfall » est une métaphore de la construction appliquée, à l'origine à demi critique, au code. Les « sprints » empruntent à l'athlétisme ; les « pipelines » de delivery au pétrole et au gaz ; les « war rooms » au militaire ; le « triage » de la médecine de champ de bataille à la gestion des incidents informatiques ; les « stage-gates » de la R&D chimique à presque tout le reste. Le trafic circule dans les deux sens : des hôpitaux gèrent leurs fournitures chirurgicales en kanban à la Toyota, des chantiers de construction tiennent des stand-ups quotidiens à la mode logicielle, et des banques empruntent la discipline de « site reliability » aux grandes plateformes technologiques. Cet emprunt n'est pas décoratif. Une métaphore qui migre avec succès transporte une théorie comprimée du travail — et ses frictions, là où la métaphore épouse imparfaitement la nouvelle industrie, sont précisément là où commence la prochaine adaptation de la discipline. La gestion de projet n'a jamais évolué par invention ex nihilo ; elle évolue par larcin, traduction et mise à l'épreuve du terrain. Le praticien qui lit à travers les industries, plutôt qu'au-dedans d'une seule, lit l'avenir de la discipline avec dix ans d'avance.