Options réelles
Les options réelles indiquent à quel moment un engagement doit être pris, sans dire lequel prendre. Chaque décision encore ouverte est tenue pour une option et reçoit une échéance, datée ou conditionnelle. L'engagement se prend juste avant que l'option ne disparaisse, au dernier moment responsable: la dernière date à laquelle la décision se prend encore sans coût supplémentaire. Chris Matts et Olav Maassen ont formulé la technique en 2007 en trois règles: une option a de la valeur, une option expire, ne jamais s'engager tôt sans savoir pourquoi. L'Agile Extension au guide BABOK note qu'elle sert couramment à l'affinement et à la priorisation. Le nom vient de la finance d'entreprise, où les options réelles se valorisent par des modèles de prix; la version employée en business analyse n'en garde aucune mathématique.
Objectif
Les options réelles servent à fixer le moment d'une décision. Pour chaque décision encore ouverte, la technique établit la date ou la condition au-delà de laquelle le choix disparaît, puis place l'engagement juste avant ce point.
Devant une information incomplète, un groupe s'engage trop tôt pour faire cesser l'inconfort de l'incertitude. Matts et Maassen partent de cette aversion: une décision prise trop tôt a plus de chances d'être fausse, parce que l'information n'était pas encore là. La technique inverse l'ordre: l'échéance d'abord, la collecte de l'information ensuite, jusqu'à cette date.
Le livrable est un registre des options: une ligne par décision ouverte, son échéance, le dernier moment responsable qui la précède, l'information qui doit arriver d'ici là et ce qu'il en coûte si l'option se ferme.
La technique dit quand décider et reste indifférente à la façon dont la décision se prend. Le choix lui-même relève de l'analyse décisionnelle: les options réelles fixent le jour où cette évaluation doit être conduite, l'analyse décisionnelle départage les variantes ce jour-là.
Usage
Quand l'utiliser
- Choix de fournisseur ou d'architecture sous information incomplète: dater l'échéance et instruire les candidats jusque-là.
- Attente d'un acte externe: entrée en vigueur d'une norme, arbitrage de comité, publication d'une version; l'échéance se rattache à cet événement.
- Offre commerciale à validité limitée: l'échéance est datée et le coût de la manquer se chiffre.
- Décision irréversible et coûteuse: migration de plateforme, choix de format de données, engagement pluriannuel.
Quand ne pas l'utiliser
- Aucune information nouvelle attendue d'ici l'échéance: l'attente n'améliore pas le choix, conduire l'analyse décisionnelle tout de suite.
- Coût de maintien supérieur à l'écart entre les variantes: le chiffrer par une analyse coûts-bénéfices et s'engager.
Description
Les trois règles
Chris Matts et Olav Maassen ont posé ces trois règles en 2007; l'Agile Extension les reprend.
Une option a de la valeur. Garder une possibilité ouverte donne une marge de manœuvre: l'équipe absorbe un retour d'utilisateur, un apprentissage technique ou un changement de besoin sans défaire un engagement. Maintenir deux intégrations candidates coûte du temps d'étude, parfois du développement. Ce coût de maintien se budgète au moment où l'option s'ouvre.
Une option expire. Une possibilité qui ne disparaît jamais n'oblige jamais à décider, donc elle n'apporte aucune valeur. L'échéance transforme une hésitation en option: elle fixe le point après lequel le choix disparaît, ce qui rend la décision programmable.
Ne jamais s'engager tôt sans savoir pourquoi. Un engagement précoce reste légitime quand sa raison se nomme: un rabais qui expire, une équipe bloquée tant que la décision n'est pas prise, un composant à commander avec six semaines de délai. La règle proscrit l'engagement pris pour dissiper l'inconfort, dont personne ne sait dire ce qu'il fait gagner.
L'option et la fausse option
Une option est une possibilité que l'organisation détient: elle peut l'exercer ou la laisser passer et elle sait quand elle disparaît. Une user story est une option d'implémenter une fonctionnalité, qui expire quand le besoin métier change. Des critères d'acceptation sont l'option d'écrire un niveau de détail donné pour cette story. Une réservation d'hôtel est une option de loger, qui expire à 18 heures le jour du séjour, après quoi la nuit est due.
L'Agile Extension liste cinq situations qui produisent une fausse option: ce que l'organisation ne sait pas faire, ce qu'elle n'a pas les moyens de payer, ce qu'elle ne peut pas mener dans le temps disponible, ce qui ne s'achète ni ne se vend, ce pour quoi elle n'a pas l'outillage. Une variante qui tombe dans l'une d'elles occupe une ligne du registre en donnant l'illusion d'un choix. Le test se pose à l'ouverture: qui exercerait cette option, avec quels moyens, dans quel délai?
Déterminer l'échéance
En finance, l'échéance d'une option est contractuelle et datée. En business analyse, elle est le plus souvent conditionnelle: elle se rattache à un événement dont la date reste inconnue, l'épuisement du budget de l'exercice, la sortie d'une version, le départ d'un partenaire. L'Agile Extension nomme la détermination de l'échéance l'aspect le plus important de la technique.
Elle se calcule à rebours. On part du moment où l'engagement doit être honoré: la mise en production, la signature, le passage de commande. On en retranche le temps d'exécution incompressible: validation juridique, délai de livraison du prestataire, durée de l'intégration. Le résultat est le dernier moment responsable. Ce raisonnement qui remonte des sorties vers les entrées est celui que l'Agile Extension signale comme contre-intuitif; elle ajoute que la technique demande de la pratique avant de devenir un réflexe.
Pour chaque option, on nomme ce qui doit être su avant le dernier moment responsable et qui le produira: un essai technique, une réponse chiffrée du prestataire, un avis du régulateur. L'intervalle qui précède l'échéance devient un programme de collecte, avec ses tâches et ses responsables. Quand l'information n'arrivera manifestement pas à temps, l'option se ferme tôt et le repli devient explicite.
L'engagement et sa pénalité
L'engagement ferme les autres options et porte le plus souvent une pénalité en cas de manquement. Trois exemples: le langage de développement standard de l'organisation, les critères d'acceptation terminés avant l'atelier de planification et les éléments du backlog que l'équipe s'est engagée à livrer. S'écarter du premier coûte en risque et en maintenance; manquer le dernier entame la confiance du client. Écrire la pénalité rend l'échéance opposable: une date sans conséquence connue se renégocie à chaque séance.
Le calendrier des décisions s'aligne sur les rendez-vous existants. Dans une initiative menée en itérations, la prochaine occasion de décider est la séance de planification; dans une initiative conduite en flux, c'est le moment où de la capacité se libère. Une option dont l'échéance tombe entre deux rendez-vous se traite au rendez-vous précédent, ce qui avance son dernier moment responsable d'autant.
Ce qui fait échouer la technique
L'option qu'on n'a pas datée
Un sujet déclaré ouvert sans échéance est un report. Le registre se remplit de décisions différées dont personne ne sait quand elles reviennent. Une option sans échéance, datée ou conditionnelle, sort du registre et se tranche à la séance suivante.
L'engagement pris par défaut
Une échéance que personne ne surveille se franchit sans décision, et le repli s'applique sans que quiconque l'ait choisi ni argumenté. Chaque ligne du registre porte donc un nom de responsable et un rappel daté au dernier moment responsable. La surveillance est la part de la technique qui survit le moins bien à un changement de personne, parce qu'elle ne produit rien tant que rien n'arrive à échéance.
L'option qu'on n'a pas entretenue
Garder une option ouverte demande du travail. Deux intégrations restent des options tant que chacune pourrait être livrée dans le délai. Si l'équipe n'a instruit que la première, la seconde a expiré bien avant sa date, sans que le registre l'ait enregistré, et le groupe se croit encore libre de choisir. La revue d'échéance porte donc sur deux questions: la date a-t-elle bougé et l'option est-elle encore exerçable?
La technique confondue avec le choix
Un registre bien tenu indique le jour où il faut décider et laisse entière la question de savoir quoi décider. Les groupes qui s'arrêtent au registre arrivent à l'échéance sans critère d'évaluation et tranchent dans l'urgence. La date sert à programmer l'évaluation, matrice de décision, analyse coûts-bénéfices ou toute autre méthode, assez tôt pour qu'elle tienne.
Considérations IA
Un modèle de langage prépare le registre. À partir d'un export de backlog, d'un compte rendu d'atelier ou d'un fil de discussion, il extrait les décisions restées ouvertes, ce qu'un relevé manuel rate parce que la décision ouverte s'écrit rarement comme telle: elle apparaît sous la forme « on verra avec le prestataire » au milieu d'un compte rendu. Il propose ensuite pour chaque ligne une formulation d'échéance et l'information manquante associée.
La surveillance se délègue aussi. Un agent branché sur l'agenda, sur les dates de validité des offres et sur le suivi contractuel signale les derniers moments responsables qui approchent, tâche répétitive dont l'oubli produit l'engagement pris par défaut.
La détermination de l'échéance ne se délègue pas. Elle repose sur des faits internes que le modèle n'a pas: les termes d'un contrat, le calendrier du régulateur, le délai de livraison qu'un fournisseur tiendra, la capacité de l'équipe le trimestre prochain. Un modèle interrogé sur une échéance produit une date plausible, avec la même assurance qu'une date vérifiée. L'échéance n'est recoupée par aucune autre donnée du registre, si bien qu'une date inventée n'y rencontre aucune contradiction. Sollicité sur une décision ouverte, il recommande une variante alors que la question portait sur une date. Un registre des options nomme les fournisseurs pressentis, les prix consentis et les points de dépendance réglementaire: sa confidentialité se tranche avant tout envoi vers un service externe.
Exemples
Une société d'assurance en ligne établie en Suisse romande construit le parcours d'entrée en relation de son portail client et doit choisir son prestataire de vérification d'identité. Le registre des options tenu par la business analyste tient en trois lignes.
| Option | Échéance | Dernier moment responsable | Coût si l'option se ferme |
|---|---|---|---|
| Intégration du prestataire de lecture biométrique | Datée: offre remisée à CHF 45'000 par an, valable jusqu'au 30 septembre | 16 septembre, soit deux semaines de validation juridique et de signature | Tarif catalogue à CHF 68'000 par an |
| Intégration SwissID | Conditionnelle: le gel du périmètre de la mise en service du trimestre, dont la date suit le calendrier de livraison | Dix jours ouvrables avant ce gel, soit le chiffrage de l'intégration, impossible avant la parution de l'orientation de la FINMA sur le niveau de vérification exigé | Mise en service décalée au trimestre suivant |
| Repli: vérification manuelle des pièces par le service client | Sans échéance | Sans objet | 0,6 équivalent plein temps au service client tant qu'il dure |
Les deux échéances sont indépendantes: l'une est fixée par une offre commerciale, l'autre par le calendrier de livraison. L'orientation du régulateur que la seconde option attend n'a pas de date connue. L'équipe s'engage à la première des deux qui se présente, et le registre chiffre ce que l'attente coûte pendant ce temps. Au 16 septembre, la comparaison porte sur les options encore exerçables: si l'orientation de la FINMA a paru, SwissID y figure, sinon la ligne sort du registre avant l'évaluation.
Prestataire biométrique
SwissID
Visualisations
La technique se dessine sur un axe de temps. Chaque option occupe sa propre ligne, du jour de son ouverture à son échéance. Ces échéances ne coïncident pas, ce que le dessin doit rendre visible. Un repère placé peu avant la fin de chaque barre porte le dernier moment responsable, et la zone située au-delà de l'échéance se grise. Le registre, lui, est un tableau.
Coût
| Phase | Niveau | Justification |
|---|---|---|
| Préparation | Faible | Les décisions ouvertes existent déjà, dans le backlog et dans les comptes rendus d'atelier. La préparation revient à les extraire et à désigner qui répond de chacune. |
| Exécution | Moyen | Établir une échéance demande de lire des conditions contractuelles, d'interroger un prestataire et de chiffrer un délai d'exécution. C'est la dépense principale de la technique. |
| Documentation | Moyen | Le registre vit au rythme des séances de planification: chaque échéance s'y revoit et une échéance conditionnelle se requalifie dès que l'événement qui la porte se rapproche. |
Outils
Les outils de gestion de backlog (Jira, Azure DevOps Boards et leurs équivalents) portent l'échéance et le dernier moment responsable dans deux champs personnalisés sur l'élément concerné. La liste devient triable par échéance au moment de l'affinement du backlog, ce qui donne l'ordre du jour de la séance. Sans ces champs, le registre vit à côté du backlog et les deux divergent en quelques semaines.
Le tableur tient le registre lorsque les décisions dépassent le périmètre d'une équipe: choix de fournisseur, engagement budgétaire, dépendance entre projets. Il conserve les lignes fermées avec la date et la raison de l'engagement, matière qui sert à réviser le calibrage des délais d'exécution.
L'agenda partagé porte les rappels: chaque dernier moment responsable devient un rendez-vous daté avec un responsable nommé.
Le tableau blanc collaboratif (Miro, Mural et leurs équivalents) sert à dessiner l'axe de temps en séance. Déplacer une barre devant le groupe fait apparaître les désaccords sur la date d'échéance plus vite qu'une discussion menée sur le registre.
La gestion contractuelle et le registre des risques alimentent les échéances: dates de validité des offres, échéances de renouvellement, délais de résiliation et risques dont la matérialisation ferme une option sont déjà suivis là. L'analyse et gestion des risques fournit l'estimation du coût du repli, qui donne à la priorisation son ordre de grandeur.
Sources
- Chris Matts et Olav Maassen, "Real Options" Underlie Agile Practices, InfoQ, 8 juin 2007: la formulation d'origine des trois règles, le lien entre aversion à l'incertitude et engagement précoce ainsi que le choix explicite d'écarter les mathématiques de valorisation des options financières.
- IIBA, Agile Extension to the BABOK Guide, §7.12 Real Options: la finalité de la technique, les quatre éléments (options, engagements, expiration des options, juste/faux/incertain), les exemples d'options et de fausses options, l'échéance conditionnelle comme aspect le plus important, ainsi que les forces et les limites énoncées.
- Stewart C. Myers, Determinants of Corporate Borrowing, Journal of Financial Economics 5(2), 1977, 147-175: l'origine du terme en finance d'entreprise.