FAQ — gestion de portefeuille de projets et pilotage agile à l’échelle
Deux façons de planifier coexistent dans les grandes organisations : le portefeuille, tenu dans un PPM, et l’agile à l’échelle, conduit dans Jira au rythme des PI. Les questions ci-dessous couvrent les deux registres, la règle qui les articule, et ce qu’une couche d’optimisation sous contraintes y apporte.
Les fondamentaux
PPM, agile à l’échelle, et la règle qui les articule.
Un PPM (Project Portfolio Management) est le référentiel dans lequel une organisation tient l’ensemble de ses projets : périmètre, jalons, charges, ressources, dépendances et priorités. Il sert à voir le portefeuille dans son ensemble plutôt que projet par projet, à décider de ce qui entre et de ce qui attend, et à conserver la trace des arbitrages.
Ce qu’un PPM apporte : une vue consolidée, un langage commun entre directions, et la traçabilité des engagements. Ce qu’il ne fait pas : calculer. Il enregistre et propage un plan, il ne le construit pas. La décision d’insérer un projet, de décaler un jalon ou de déplacer une équipe reste un arbitrage humain, le plus souvent préparé dans un tableur.
La gestion agile à l’échelle coordonne plusieurs équipes agiles qui contribuent à un même produit ou système. Dans le cadre SAFe, ces équipes sont regroupées en trains et se synchronisent sur un Program Increment (PI) : une séquence de quelques itérations, planifiée en une cérémonie dédiée, le PI Planning.
Planifier un PI consiste à répartir les éléments de travail entre les équipes et les itérations en respectant la capacité de chaque équipe, les dépendances entre équipes et les priorités du programme. C’est un problème d’ordonnancement sous contraintes, traité aujourd’hui à la main, au tableau blanc, sur une à deux journées.
Les deux coexistent dans la plupart des grandes organisations et ne répondent pas à la même question. Le portefeuille décide de ce qui est engagé et à quelle échéance ; l’agile à l’échelle décide de la façon dont l’engagement se réalise, itération par itération.
La règle qui les articule tient en une phrase : la source du planning est le PPM, Jira est l’exécution. Dans une organisation pilotée depuis son PPM, un plan calculé dans Jira n’a ni autorité ni chemin de retour vers la décision : il crée un second plan, concurrent du plan officiel. Là où Jira porte réellement le plan, au contraire, c’est dans le PI Planning que la planification se joue.
Une seule question suffit : disposez-vous d’un PPM ? Si oui, c’est lui la source du planning, même si vos équipes travaillent dans Jira au quotidien ; toute optimisation doit se brancher sur le PPM et lui rendre son résultat. Si vous planifiez dans Jira, sans PPM, c’est le PI Planning qui constitue votre acte de planification, et c’est là qu’il faut intervenir.
Le cas mixte — un PPM au niveau groupe, une planification Jira autonome sur un périmètre — se tranche au niveau qui planifie réellement, pas au niveau de l’organigramme.
Une surcouche ne détient pas les données : elle les lit là où elles sont, calcule un scénario, et le restitue à l’outil d’origine. Vos référentiels restent maîtres, vos processus ne changent pas, il n’y a ni migration ni double saisie.
La différence avec un PPM tient en une phrase : un PPM vous montre l’état du portefeuille, une surcouche d’optimisation vous propose un ordonnancement qui respecte vos contraintes et vous laisse le comparer à d’autres.
Piloter un portefeuille de projets avec un PPM
Arbitrage, capacités, insertion de projets — le registre de KoAlign.
Quatre familles structurent l’outil : la tenue du référentiel projets (périmètre, jalons, livrables), la gestion des ressources et des capacités, le suivi de l’avancement réel et du reste à faire, et la consolidation de portefeuille — priorisation, scénarios, reporting de direction.
La limite est toujours la même : un PPM vous signalera qu’une équipe est surchargée au deuxième trimestre ; il ne vous dira pas quel ordonnancement du portefeuille supprime cette surcharge sans décaler vos projets prioritaires.
C’est la question qui déclenche le besoin : si j’insère ce projet avec cette priorité, quel est l’impact sur le reste du portefeuille ? Y répondre à la main suppose de propager, projet par projet, l’effet d’une demande nouvelle sur des capacités partagées — ce que personne ne fait au-delà de quelques dizaines de projets.
Une optimisation de portefeuille traite le problème globalement : elle produit un ordonnancement complet sous vos contraintes de capacité, d’antériorité et de priorité, et l’enregistre comme une version. Vous comparez les versions entre elles ; la version retenue devient l’engagement, et reste consultable.
Non — et c’est l’inverse de ce qu’il faut faire. Remplacer un référentiel de portefeuille est un projet à part entière : migration, reprise des habitudes, conduite du changement. L’optimisation se branche sur le PPM en place : ingestion des données, calcul, restitution dans l’outil. Le processus de décision existant n’est pas perturbé, il est alimenté.
La visibilité utile n’est pas le pourcentage d’avancement affiché : c’est l’écart entre l’engagement pris et le reste à faire estimé. Le premier se fige lorsqu’une version est retenue ; le second se met à jour au fil de l’exécution. Comparer les deux, période par période, fait apparaître la divergence du plan avant que le retard ne soit constaté.
Ce suivi suppose que l’engagement soit une donnée et non un souvenir : c’est le rôle du versionnement des scénarios.
De cinq à dix jours de travail entre le premier fichier client et la première simulation : une charge unique, non récurrente. Ce délai s’étale en général sur environ deux mois calendaires, dominés par les temps de réponse côté client bien plus que par la charge technique ; l’engagement d’un sponsor de direction le raccourcit nettement.
Un connecteur se développe une fois par PPM puis se réutilise ; seul le mapping vers votre référentiel vous est propre. Le connecteur Primavera P6 est opérationnel.
De dix à trente minutes dans un cas courant, jusqu’à une heure sur les portefeuilles les plus lourds. Un cycle d’arbitrage complet — trois à cinq simulations comparées — représente une demi-heure à deux heures et demie de calcul. En pratique : on lance, on traite autre chose, on revient dans la demi-journée.
Préparer et conduire un PI Planning
Agile à l’échelle et SAFe sur Jira — le registre d’AlignIQ.
À partir de cinq équipes et cinq epics, la faisabilité d’un PI ne se vérifie plus à la main. L’argument n’est pas le nombre de combinaisons : c’est que la vérification porte simultanément sur cinq équipes et cinq itérations, soit vingt-cinq enveloppes de capacité, auxquelles s’ajoutent les dépendances entre équipes. Une trentaine d’éléments de travail suffit à placer l’exercice hors de portée d’une relecture humaine.
En deçà, un tableau blanc et une relecture attentive suffisent. Au-delà, ce qui sort de la cérémonie est un plan plausible, pas un plan vérifié.
Trois éléments doivent être réunis avant la cérémonie : la demande (les éléments de travail candidats, leurs estimations, leur rattachement d’équipe), la capacité de chaque équipe pour chaque itération, et les priorités du programme. Les deux premiers sont de nature différente : la demande vient de Jira, la capacité se pose avec les équipes.
La cérémonie change de nature lorsque la faisabilité se calcule pendant la séance : on ne discute plus de savoir si le plan tient, on choisit parmi les scénarios qui tiennent.
Pour la demande, oui : les tickets, leurs estimations de charge et leur rattachement d’équipe y sont, et ils sont d’autant plus complets que Jira porte réellement le plan. Pour la capacité, non — et il ne faut pas la lui demander. La capacité par équipe et par itération se saisit en séance, avec les participants : c’est une donnée de décision, pas une donnée de ticket.
Une dépendance est une contrainte d’antériorité entre deux éléments portés par deux équipes différentes : elle contraint l’itération d’arrivée autant que la charge. Traitées à la main, les dépendances se découvrent en séance, sur des fils tendus au tableau, et les plus coûteuses se découvrent après.
Traitées comme une contrainte du problème, elles ne sont plus une découverte : un plan qui violerait une antériorité n’est pas produit, et les dépendances non résolues entre trains se signalent d’elles-mêmes.
Non. Un tableau blanc collaboratif sert à conduire la séance et il le fait bien. Ce qu’il ne sait pas faire, c’est vérifier que le plan posé tient : capacités respectées, dépendances satisfaites, priorités honorées. L’enjeu n’est pas de remplacer l’espace de travail, mais d’y ajouter le calcul de faisabilité.
Un plug-in Jira, puis le paramétrage des équipes et de leurs capacités : environ une demi-journée accompagné, une journée en autonomie. C’est non récurrent. Du premier fichier client à la première simulation : une journée. Ensuite, une simulation dure cinq minutes — une journée de paramétrage, puis un clic à chaque PI.
Aucun lien avec un PPM n’est nécessaire : la préparation d’un PI fonctionne sur Jira seul, avec Advanced Roadmaps ou Azure DevOps le cas échéant.
L’IA, les données et l’intégration
Ce que fait le moteur, ce qu’il n’apprend pas, et comment il se branche.
Trois familles d’intelligence artificielle interviennent, pour trois usages distincts. L’apprentissage automatique exploite vos historiques de projet pour estimer délais, coûts et aléas. L’optimisation combinatoire — algorithmes évolutionnistes — évalue simultanément de multiples scénarios pour trouver le meilleur ordonnancement des tâches et la meilleure allocation des ressources sous vos contraintes. L’IA générative synthétise l’information textuelle : retours d’expérience, comptes rendus, documents de synthèse.
Elles ne se remplacent pas, elles se complètent. Le détail de ces trois familles est présenté sur une page dédiée.
Non, et la distinction est importante. L’optimisation repose sur un algorithme génétique : de l’IA classique, pas un modèle de langage. Les contraintes et le critère à optimiser sont déclarés, donc lisibles, discutables et modifiables. Rien n’est appris sur vos données : le problème est posé, il n’est pas induit.
Pas nécessairement. Une recherche stochastique peut produire, sur les mêmes données, deux plans admissibles différents. C’est une propriété, pas un défaut : plusieurs exécutions produisent plusieurs plans admissibles, et ce sont eux que l’on compare. Chaque exécution est archivée en version, de sorte que le plan retenu reste consultable et opposable.
On n’audite pas la recherche, on audite le résultat. Tout plan produit se vérifie ligne à ligne : capacités respectées, antériorités satisfaites, priorités honorées — indépendamment du chemin qui l’a trouvé.
Le point de comparaison n’est pas l’optimum mathématique : le problème est NP-difficile au sens fort, et à l’échelle d’un portefeuille réel personne ne calcule l’optimum. Le plan respecte toutes vos contraintes, il se vérifie, et il est meilleur qu’un arbitrage à la main.
Trois réponses, qui vont ensemble. Rien n’est appris sur vos données : aucun modèle n’est entraîné avec. Le déploiement peut être réalisé sur votre infrastructure, auquel cas les données de projet ne sortent pas de votre système d’information. Et les données confiées dans le cadre d’un POC sont traitées pour la durée du POC, puis effacées de nos serveurs à l’issue : c’est ce qui a été fait sur le dernier en date.
Oui. Le choix ne se tranche pas en termes de sécurité absolue mais de gouvernance : un déploiement sur site maintient les données de portefeuille à l’intérieur de votre périmètre et les place sous vos propres politiques, ce qui lève l’essentiel des questions posées par la sécurité des systèmes d’information et les fonctions juridiques. Un hébergement mutualisé réduit en contrepartie la charge d’exploitation. Les deux modes sont possibles.
De quelques dizaines à plusieurs centaines de milliers d’éléments de travail. Le point haut mesuré à ce jour : le moteur a traité 200 000 tâches en moins de deux heures, en lecture et écriture de fichiers tabulaires, sur le portefeuille réel d’un grand compte industriel. Le passage à l’échelle est l’un des quatre piliers de la solution, avec l’optimisation sous contraintes réelles, la simulation interactive et l’intégration non intrusive.
Par lecture et restitution, jamais par migration. Côté portefeuille, un connecteur dédié au PPM ; côté agile, un plug-in Jira, avec Advanced Roadmaps ou Azure DevOps. Dans les deux cas, les données maîtres restent chez vous et l’outil d’origine demeure la référence de vos équipes.
Le problème traité est une instance de RCPSP (Resource-Constrained Project Scheduling Problem), étudiée depuis les travaux de Blazewicz, Lenstra et Rinnooy Kan (1983), puis de Kolisch et Hartmann (2006) et de Hartmann et Briskorn (2010, mis à jour en 2022).
Les algorithmes font l’objet d’un partenariat de recherche en cours avec le LIX (UMR 7161, CNRS / École polytechnique / IP Paris), avec validation expérimentale sur les jeux de référence PSPLIB et MMLIB. La modélisation probabiliste des aléas fait l’objet d’une collaboration en cours avec le LGI de CentraleSupélec : développement en cours, et non une fonction disponible aujourd’hui.
Une question qui n’est pas dans cette liste ?
Trente minutes pour confronter votre contexte de pilotage à nos moteurs.
Réserver une démo