Un projet, deux horloges

Une équipe produit développe un flux de travail assisté par l’IA. La qualité du modèle est incertaine, les utilisateurs ne s’entendent pas sur la bonne interaction et chaque test modifie ce que l’équipe pense devoir construire ensuite. De courtes itérations constituent la façon raisonnable de travailler.

Le lancement de ce même projet est lié à un grand événement sectoriel. Le marketing a réservé l’espace. Des démonstrations aux clients sont planifiées. Une revue de sécurité doit être terminée six semaines plus tôt et une soumission gouvernementale doit respecter une période fixe.

L’équipe travaille par itérations, mais l’entreprise avance vers des dates qui, elles, ne bougeront pas.

On présente souvent cette situation comme un choix entre agile et cascade. Ce n’est pas le bon choix. Le projet fonctionne selon deux horloges, et chacune exige une forme de gestion différente.

L’horloge de l’apprentissage et celle de l’engagement

Le développement de l’IA convient particulièrement bien à l’horloge de l’apprentissage. Les équipes savent rarement à l’avance quel modèle, quelle méthode de recherche, quelle structure de requête, quel jeu d’évaluation ou quel contrôle humain produira un résultat acceptable. La découverte produit, l’optimisation des performances et une grande partie de la R-D suivent la même logique.

Les horloges sont liées, mais elles ne sont pas interchangeables. Les itérations produisent des preuves. Les jalons s’appuient sur ces preuves pour débloquer des fonds, accepter un risque, modifier le périmètre ou arrêter le travail.

Une date fixe ne transforme pas le travail en cascade

La cascade n’est pas un autre mot pour désigner la planification. Elle décrit un déroulement principalement séquentiel dans lequel une phase est censée se terminer avant que la suivante commence. Cette approche peut être tout à fait appropriée lorsque le travail est bien compris, que les changements coûtent cher et que l’ordre des opérations est réel.

Une date fixe ne rend toutefois pas un travail incertain prévisible. Donner à un programme d’entraînement d’IA un plan de tâches détaillé sur douze mois n’élimine pas l’incertitude. Cela ne fait que consigner des hypothèses comme s’il s’agissait de faits.

L’erreur inverse consiste à prendre l’incertitude comme prétexte pour ne prendre aucun engagement. Les dirigeants ne peuvent pas réserver du capital, coordonner des partenaires ou approuver des dépenses de marketing à partir d’un carnet de produit dont la réponse à chaque question est que les priorités peuvent changer.

Les principes du Manifeste agile mettent l’accent sur des logiciels opérationnels, des livraisons fréquentes et l’adaptation aux changements d’exigences. Ils ne disent pas que les entreprises doivent cesser d’établir des budgets, de gérer les risques ou de coordonner leurs obligations externes. Le Project Management Institute décrit lui aussi un continuum d’approches, de la méthode prédictive aux méthodes itératives, incrémentales et agiles, les approches hybrides combinant les pratiques selon la nature du travail plutôt que d’imposer une méthode unique à tout un projet (PMI, A Spectrum of Approaches to Project Agility).

La question utile n’est pas : « Sommes-nous agiles ? » Elle est : « Quelles parties de ce travail peuvent être prévues, lesquelles doivent faire l’objet d’un apprentissage et où l’organisation doit-elle prendre une décision ? »

Construire les jalons autour des décisions, pas des documents

Un jalon doit exister parce qu’une personne doit prendre une décision lourde de conséquences. Terminer un document n’est pas une décision d’affaires.

Voici quelques jalons utiles :

• Approuver une expérience de plus grande ampleur après qu’une petite expérience a atteint un seuil de qualité défini
• Engager les dépenses d’infrastructure de production après avoir mesuré la charge et les coûts
• Entamer un processus de validation réglementé après la stabilisation de la conception
• Débloquer les dépenses de marketing après que le produit a démontré le parcours client requis
• Migrer les clients après avoir testé les procédures de retour arrière, de soutien et de gestion des incidents
• Arrêter un projet lorsque les preuves ne soutiennent plus son dossier d’affaires

Cette structure donne à l’équipe itérative l’espace nécessaire pour apprendre, tout en offrant au reste de l’entreprise un point fiable où l’apprentissage se transforme en engagement.

Planifier à rebours, apprendre vers l’avant

Commencez par planifier à rebours depuis l’événement externe. Repérez les délais d’approvisionnement, les périodes d’approbation, les gels d’intégration, les périodes de formation, les préavis aux clients et les autres dépendances qui contraignent réellement le calendrier. Ce sont des faits à gérer, pas des récits qu’une estimation peut faire disparaître.

Ensuite, avancez par courts cycles de production de preuves. L’équipe mène des expériences, livre des portions limitées et met à jour sa compréhension. Le contenu des travaux ultérieurs peut changer, pourvu que les preuves nécessaires au prochain jalon arrivent à temps.

Enfin, protégez une solution de repli viable. Si une démonstration lors d’une conférence exige que le modèle atteigne une précision de 95 %, décidez à l’avance de ce qui se passera à 90 %. La solution de repli pourrait réduire le cas d’utilisation, ajouter une revue humaine, utiliser un flux de travail déterministe pour une partie du processus ou modifier la démonstration. Découvrir cette solution deux jours avant l’événement ne relève pas de l’agilité, mais d’une gestion tardive du risque.

Séparer les prévisions des engagements

Les équipes perdent la confiance de l’organisation lorsque chaque estimation est entendue comme une promesse. Les dirigeants perdent le contrôle lorsque chaque promesse est ensuite décrite comme une estimation.

Utilisez un vocabulaire différent selon le degré de certitude :

Un premier prototype d’IA peut avoir une cible et une prévision. Une soumission réglementaire constitue un engagement. La décision d’inclure la capacité d’IA dans cette soumission est un jalon.

Ce vocabulaire empêche une estimation du carnet de produit de devenir discrètement une date de lancement publique.

Adapter la méthode au chantier

Un même programme peut comprendre plusieurs chantiers qui suivent des méthodes opérationnelles différentes.

L’évaluation d’un modèle d’IA peut être très itérative. L’installation d’un centre de données peut être essentiellement prédictive, car les équipements, les permis et l’enchaînement physique imposent de véritables dépendances. Une validation gouvernementale peut exiger des preuves et des délais de revue prescrits. L’intégration de clients peut se faire par déploiement incrémental auprès de cohortes successives.

Forcer ces quatre chantiers à suivre le même rituel crée des frais généraux sans améliorer le contrôle. Un programme plus solide donne à chaque chantier la méthode dont il a besoin et les relie par des jalons, des risques et des points de décision communs.

Voilà ce qu’est une livraison hybride utile. Ce n’est pas un compromis à mi-chemin entre deux méthodologies. C’est une conception explicite permettant de coordonner des travaux dont les degrés d’incertitude diffèrent.

Le système de gestion minimal

La feuille de route devrait rester stable au niveau des résultats d’affaires et des jalons. Le travail entre ces jalons peut changer.

Le leadership relie les deux horloges

La partie la plus difficile consiste rarement à choisir un cadre de gestion de projet. Elle consiste à maintenir un lien honnête entre l’apprentissage technique et l’engagement d’affaires.

Quelqu’un doit décider quand les preuves sont suffisamment solides, quand l’incertitude demeure acceptable, quand le périmètre doit évoluer et quand une promesse externe ne devrait pas être faite. Cette personne doit aussi posséder assez de profondeur technique pour remettre en question une expérience faible et assez de contexte commercial pour comprendre le coût de l’attente.

C’est souvent le rôle manquant dans une entreprise de taille moyenne. L’équipe d’ingénierie peut mener les itérations. L’équipe de direction peut fixer les dates. Aucun des deux groupes, à lui seul, n’assume nécessairement la traduction entre les deux.

Un bon modèle opérationnel ne rend pas certain un travail incertain. Il rend l’incertitude visible assez tôt pour que l’entreprise puisse agir.