En cette période de crise épidémiologique et de confinement, les approches PPM apportent chacune leurs qualités pour affronter les risques. Mais comment se distinguent-elles ?
Risque, incertitude, responsabilité : des visions distinctes selon deux approches
Les circonstances de la crise sanitaire actuelle, sont une occasion pour nous, professionnels des projets, d’être interpellés sur la dimension gestion des risques qui nous est essentielle. Comment est-elle appréhendée selon les approches Traditionnelle et Agile de gestion de produits, de projets et de portefeuilles ? En quoi ces approches sont différentes l’une de l’autre ?
Que l’on fasse cette observation au niveau opérationnel des projets ou au niveau de la supervision du portefeuille des projets, on constate que leurs notions « d’incertitude », de « risque », et de « responsabilité » les déterminent et les distinguent à la fois.
Que l’on parle d’une approche cycle en V, Cascade ou Stage/Gate applicable aux projets elles sont rattachées à une vision traditionnelle de la gestion qui se caractérise par une forte exigence d’anticipation des événements par la planification et le contrôle. A contrario, l’approche Agile est par définition une réponse à l’incertitude grandissante à laquelle font face les projets et portefeuilles de projets. Pour y parvenir, parmi les principes inscrits dans le manifeste Agile, on retrouve l’adaptation par rapport au plan et l’autonomie de décision. Cette posture d’adaptation aux circonstances implique celle de l’aptitude à agir en réaction aux événements et changements qui surviennent dans le déroulement des projets et des produits. Mais, face à la crise sanitaire du Covid-19 et à ses implications à la fois économiques, politiques et sociales que proposeraient ces approches en termes de traitement des risques ? La probabilité de la mise à l’arrêt de la société civile est allée grandissante en moins de deux mois, jusqu’à devenir une réalité aujourd’hui.
Un modèle du risque proactif ou réactif pour y remédier
Si nous sommes tous familiers avec la définition et les modalités classiques de gestion des risques, ce sont les divergences de considération de ce processus de gestion selon ces deux approches qu’il est intéressant d’analyser.
Classiquement, avec l’approche traditionnelle, l’identification, la qualification et la réduction des risques participent de la planification et du pilotage des projets et portefeuilles. Il est essentiel de s’appuyer sur une base de risques déjà identifiée et d’une taxonomie des risques la plus ouverte possible tout en étant spécifique à l’activité de l’entreprise. L’expérience vécue par la Chine et observée pendant les premières semaines de l’année a pu servir de référence à de nombreux chefs de projets pour deux raisons. Elle a relevé progressivement la probabilité de l’épidémie à son niveau maximum pour devenir la réalité que l’on connait. Mais, elle a aussi servi de modèle pour figurer et projeter les impacts de son expansion à un point que personne n’avait encore imaginé. La maturité de chacun face aux risques a donc permis d’atténuer les effets de la criticité de ceux identifiés à mesure que l’épidémie prenait place. Les plans de charge des projets et des portefeuilles ont été révisés et les calendriers aussi.
Pour ce qui est de l’approche Agile, la notion de risque est plus difficile à isoler, puisque son esprit pousse à la réactivité face aux événements. Sans intention d’anticipation dans les projets et les portefeuilles et la continuité de services des équipes produits, le parti pris est celui de traiter des problèmes par l’adaptation des méthodes et des livrables au fil des itérations sans que cela n’en dégrade la qualité, qui constitue son principal levier de décision. En l’absence de culture du risque, les acteurs des équipes Agile s’en remettent plus à l’intuition du groupe qu’à la raison des experts. Qu’en est-il lorsque un à un les membres de l’équipe deviennent indisponibles pour raison médicale ou privée ? Enfin les pratiques rigoureuses de cette approche se retrouvent mises à mal par la perte de l’unité de lieu des acteurs imposée par le confinement et le recours au télétravail. Le leitmotiv du « time to market » pour satisfaire le client est momentanément inaccessible.
La gestion du risque : extension de la responsabilité
La gestion des risques se définit par son exigence d’anticipation des événements pouvant faire obstacle aux objectifs visés. Pour ce faire, il faut convenir d‘hypothèses de réduction de son occurrence et de ses effets qui peuvent prendre la forme de contingences retranscrites dans la planification. Tout le travail des responsables tient à identifier, qualifier et envisager ces mesures de réduction en adéquation avec les moyens à leur disposition.
Dans le cas de l’approche classique, la responsabilité de la culture du risque est portée par la ligne managériale, puisque par délégation, il est du ressort du chef de projet de concevoir et d’animer la trajectoire du projet qui vise le résultat dans les termes annoncés au client. Cette forme de déclinaison de la prospective à l’exercice de la planification s’appuie sur la production de scénarios liés à des opportunités et à des risques auxquels des hypothèses de « survenue » sont associées. Lorsque cet exercice est entretenu tout au long des projets, il implique à son tour une révision régulière pour ajuster les hypothèses en privilégiant le levier de pilotage dominant : le temps, le budget, la valeur client. Reste qu’une telle démarche est très consommatrice de temps et se retrouve, dans les faits, incompatible avec l’accumulation des fonctions des chefs de projet. Néanmoins, dans les circonstances actuelles, la coordination des différentes activités et des prises de décisions, de plus en plus souvent réalisée à distance, ne souffre pas de la mise en place du télétravail comme solution de continuité des activités même si les contingences déterminées à l’engagement des travaux ne seront pas suffisantes.
A l’inverse, dans le cas de l’approche agile, la responsabilité est collectivisée au niveau de l’équipe. Les membres de l’équipe mis en situation d’autonomie basée sur la confiance, se retrouvent porteur chacun d’une part de responsabilité. Cette dernière intègre les considérations de l’incertitude, des évolutions de l’environnement interne et dans une moindre mesure externe. Cependant pour exercer cette responsabilité, c’est par leurs interactions en face à face que leur crédo « on fait avec et la vie continue » leur permet d’assumer et de résoudre les problèmes rencontrés. Dans les circonstances actuelles, le mode projet agile résiste bien de par sa capacité à gérer le chaos, au moins tant qu’il n’est pas rendu inopérant par trop de bouleversements.
Les 2 approches résistent à la crise
En fin de compte, aucun des deux modèles n’est pris en défaut. Si l’un privilégie l’anticipation des opportunités et obstacles à la planification en se donnant les moyens de les réduire, et si l’autre est focalisé sur la capacité à délivrer quelques soient les circonstances sans se préoccuper de prévoir des contingences. Ces deux modèles sont à même de faire face à des événements imprévus.
De son côté le Bureau des Projets compose son propre modèle de gestion de produits, de projets et de portefeuille. Historiquement géré en approche traditionnelle, il adopte quelques éléments des pratiques agiles « façon puzzle » (comme l’effort de développer l’autonomie ou la capacité à innover). Sans reprendre suffisamment les principes des approches dont il s’inspire, pour causes de manque de moyens, de temps, de conviction ou d’appui de la Direction, le bureau projet se contente de mettre en place quelques rôles, artefacts et cérémonies. Mais dans ces conditions sa transformation échoue à interpréter le changement de paradigme qu’elle recherche. Parce que, l’interprétation du traitement des risques dans toutes ses dimensions n’en deviendra ni cohérente ni complète. A qui la faute ?
Globalement, on peut donc être rassuré. Ces deux approches de gestion de projets et portefeuille projets peuvent faire face chacune à leur manière à la crise actuelle, comme les Etats le démontrent à leur niveau. La Chine a pris le parti de la planification de mesures jusqu’à effet complet. Tandis qu’en Europe et notamment en France, la résolution est préférée en réactivité aux constats avec des consignes révisées au fil des itérations de plus en plus rapide à mesure que les faits s’accélèrent.
Dans ces conditions, quel que soit l’approche choisie, il faut convenir qu’il est essentiel de développer collectivement et individuellement une culture du risque aussi légitime que le sont celles de la qualité ou de la valeur client. Elle est indispensable face à l’incertitude grandissante de nos sociétés qui perd jours après jours son insouciance.
La transformation digitale mène les entreprises à rechercher un modèle de gestion de leurs portefeuilles de projets capable d’appréhender les projets « Marathon » (cycle long, cycle en V) autant que les « Sprint » (cycle court, Agile, Lean, Kanban). L’approche « Bimodal IT », introduite par le Gartner, n’a pas fini d’apporter ses réponses aux appels à l’aide des équipes de développement Agile face à un management encore traditionnel.
L’approche « Bimodal IT » pour structurer les projets marathon et les sprint …
En 2014, le Gartner avait identifié avec précision une tension cruciale provenant de la prolifération des demandes IT. Aujourd’hui plus qu’hier, les métiers ont besoin de personnalisations, d’évolutivité et d’efficacité et pas seulement de logiciels et d’applications monolithiques. Pour y répondre, le Gartner, soutien que son approche « Bimodal IT » favorise l’innovation, la transformation digitale des métiers et l’amélioration. En cela, il postule que les organisations informatiques de l’avenir œuvreront selon deux modes distincts. Le mode 1 lié à l’informatique traditionnelle, est axé sur la stabilité et l’efficacité, tandis que le mode 2 qui tient de l’organisation agile est axé sur le time-to-market, l’évolution rapide des applications et, en particulier, l’alignement étroit avec les lignes métiers. Notons que bien souvent l’organisation agile demeure expérimentale pour beaucoup d’entreprises.
… mais comment gouverner un portefeuille constitué de projets si différents ?
En cinq ans, le monde anglosaxon de la gestion de projet a donc résolu la cohabitation des approches cycle en V et cycle agile avec le concept de Bimodal IT. Cependant, l’extension de l’approche à la gestion de programme et de portefeuille de projets est très peu débattue. Est-ce par méconnaissance ou refus de la nouveauté ? Ou parce que cette cohabitation des modèles marathon et sprint est déjà pleinement résolue dans les organisations ? Je vous invite à corriger cette lacune en vous livrant ce qu’il faut en connaitre.
Avec la Transformation Numérique nous sommes entrés dans une période transitoire qui nous conduit à gérer des portefeuilles de projets hybrides (IT traditionnelle / IT digitale). Si de plus en plus les projets IT sont animés en équipes Agile, il n’en est rien des programmes et des portefeuilles de projets toujours gérés selon le modèle classique de pilotage. Aujourd’hui ce modèle n’est plus en capacité de répondre au phénomène d’hybridation des portefeuilles de projets. L’objet et le rythme des activités de transformation des SI n’est plus conciliable avec les pratiques conventionnelles de gestion de portefeuille de projets. Cette course en avant vers toujours plus de flexibilité dans la transformation des organisations face aux innovations des concurrents et aux injonctions réglementaires pousse vers ce concept bimodal qui reprend les meilleures pratiques des deux mondes pour concilier stabilité et flexibilité. Il introduit néanmoins le risque d’exacerber les tensions résultantes d’une cohabitation de deux organisations en silo qui se disputent les ressources et l’influence des investissements.
A défaut, les gestionnaires de projets se retrouvent à faire le grand écart entre pilotage traditionnel de leur portefeuille par les délais et les coûts versus pilotage par la valeur et la qualité. Une équation à la fois organisationnelle, managériale et opérationnelle souvent difficiles à résoudre, d’autant plus lorsque les acteurs sont peu aptes au dialogue. A défaut encore, des Directions métiers décident de créer leurs propres équipes numériques, ce qui se traduit par de nouveaux silos et l’émergence d’une « shadow IT » qui n’est pas sans conséquence (impact sécurité, économique et pérennité de l’IT -désurbanisation du SI et dette technique-).
Un retard de mise en œuvre préjudiciable
L’extension de l’approche bimodale aux programmes et portefeuilles de projets apporterait in fine la capacité de faire travailler les équipes de l’entreprise en étroite collaboration pour atteindre la croissance et la transformation dans le monde numérique qui se dessine.
Les solutions éditeurs, les cadres méthodologiques sont à disposition mais difficilement mis en œuvre dans les organisations. En France personne n’en parle. A qui la faute ? Est-ce dû à la résistance au changement au sein des directions ? Aux lacunes conceptuelles consécutives aux castings des consultants appelés en renforts ? Ou encore à la lenteur à faire le pas vers l’introduction de pratiques agiles au sein des cellules PMO ?
La difficulté à produire une feuille de route IT/Métier et le portefeuille de projets correspondant
Historiquement, la gestion de portefeuille de projets (réalisée par la cellule PPM), est un « lieu » où la stratégie rencontre l’exécution : elle vise à transformer les « ambitions » en « plan d’action » réaliste tout en gérant les investissements et le travail. Avec l’avènement des organisations agiles, de nouvelles frictions sont apparues : cela se traduit par un manque d’harmonisation de la stratégie et de l’exécution, par des décisions d’investissement sous-optimales, par des retards à l’adoption de l’agilité, et finalement par un manque de visibilité pour tous les acteurs.
Dans l’idéal la vocation d’une cellule PPM est de produire de la visibilité sur la contribution de la DSI à la performance de l’entreprise, via l’activité projet. Les métiers étant bien souvent peu enclins à anticiper leurs transformations, c’est souvent un casse-tête pour la DSI de produire une feuille de route pour l’année à venir, un tant soit peu crédible. Pourtant, les métiers devront prochainement reconsidérer leurs relations avec la DSI en devenant responsable de la création de valeur face aux facteurs qui s’imposent (changement de l’économie, évolution des usages et des clients, consumérisation de l’informatique, accélération de la numérisation, nouveaux Business models, raccourcissement des cycles, …). Les entreprises qui réussissent le mieux à franchir le cap sont celles où un dialogue réel métier/IT existe pour l’élaboration de la feuille de route. Il n’y a pas de bons et mauvais élèves, mais l’équilibre qui rend possible le dialogue est si fragile, qu’il ne permet pas souvent de pérenniser l’approche.
En réponse à la problématique de la « bimodalité », les éditeurs ont apporté des réponses dans leurs solutions de Gestion de Portefeuille Projet, mais celles des adaptations organisationnelles et managériales doivent encore être adressées pour que les acteurs sachent utiliser au mieux les outils déployés. Car bien entendu, l’adage « un outil ne résout rien tout seul » se vérifie ici aussi. D’autant que du point de vue méthodologique, plusieurs modèles coexistent au sein des équipes. Modèles, pour lesquels l’assimilation des principes à tous les niveaux de l’organisation nécessite encore des efforts.
3 bonnes pratiques
Trois bonnes pratiques d’intégration prescrites par le Gartner peuvent atténuer les frictions et habiliter l’organisation à innover, prioriser ses investissements et délivrer plus rapidement :
La première concerne la capacité à choisir à partir d’une approche simple le modèle qui convient, basé sur la nature des projets à mener, en combinant stabilité des pratiques et flexibilité des activités. L’astuce, ici, est de préserver un mode de travail pour la recherche de différenciation et d’innovation, et un autre pour la gestion courante des projets. Pour y parvenir, mettre l’accent sur l’enjeu de création de valeur des projets est un début.
La deuxième vise à définir des objectifs d’industrialisation. Ainsi, l’organisation peut intégrer des méthodes Agile avec des méthodes traditionnelles sans sacrifier la visibilité pour les décideurs et la communication des métriques malgré les disparités d’unités de mesure. Pour ce faire, il faut déterminer des métriques précises (objectifs et résultats clés attendus), puis se focaliser sur des points très spécifiques et suivre leur amélioration au fil du temps. En effet, il ne peut y avoir d’amélioration sans mesure régulière.
Enfin, la troisièmepratiqueimplique de séparer clairement les collaborateurs en deux groupes distincts : l’un capable d’effectuer les changements au niveau de la gestion de projet ; l’autre qui sache prendre des décisions transverses à l’ensemble du portefeuille de l’entreprise. Cette distinction apporte une clarification des attributions des intervenants tout en réduisant la dépendance liée aux individus. Il s’agit, ici, de conjuguer délégation et subsidiarité dans un même environnement.
Développer une gestion de portefeuille de projet qui pilote aussi les opportunités
Pour relever ces nouveaux défis, les cellule PPM trouvent dans l’approche bimodale, un cadre de gestion du portefeuille de projets actualisé qui intègre des pratiques agiles, fournit des précisions aux équipes de projet sur la façon de communiquer l’avancement du projet, et apporte à la direction générale la prévisibilité et la responsabilisation des intervenants. C’est ainsi que l’approche bimodale est à même d’encadrer les interactions des acteurs pour éviter de compromettre tous les processus d’évolution des métiers par la cohabitation de deux organisations l’une centrée sur le client tandis que l’autre est axé sur la planification et le reporting. Cette forme de gestion du portefeuille met donc l’accent sur les opportunités (opportunités IT autant que métiers), pour tout ou partie des activités de l’entreprise, indépendamment du mode de livraison (traditionnel, agile ou hybride). Ainsi elle facilite les prises de décisions décentralisées, les analyses de rentabilité, les planning itératifs avec des objectifs décentralisés, et utilise des mesures factuelles et des jalons. Enfin autant que possible, les opportunités seront portées par des équipes agiles permanentes (squads).
En résumé, l’approche bimodale permet de résoudre les effets néfastes de la cohabitation des modèles, sans risquer de perdre la stabilité et la flexibilité qui leurs sont chère. Le mode 1 « Marathonien » leur permettra de conserver cette stabilité en faisant évoluer l’infrastructure existante de manière pérenne. Le mode 2 « Sprinter » leur permettra de développer rapidement de nouvelles solutions grâce à sa flexibilité. La transformation de l’organisation pourra être conduite en profondeur sur cette base. Elle passe avant tout par un changement culturel au sein de l’entreprise.
Tels des escadrons de cavaliers des temps modernes, les cellules PMO assistent les Dirigeants et directeurs comme le faisait en son temps les aides de camp de Napoléon et de ses maréchaux. Le contexte et les conditions ont évolué mais les exigences de visibilité et de coordination entre objectifs, ressources et contingences restent d’actualité.
De longue date, nous savons que les directions œuvrent à la transformation de l’entreprise en anticipant plus qu’en réagissant aux menaces et opportunités qu’elles rencontrent. Pour ce faire, elles gèrent leurs activités d’exploitation et d’investissement pour créer de la valeur. Les attentes sont distribuées dans toutes l’organisation (à la fois verticalement et horizontalement). Historiquement les directeurs de programmes dans les directions SI et plus récemment les directions métiers, ont mis en œuvre et développé les techniques et pratiques de Gestion de Portefeuille Projets. Chacun, à son niveau, y recherche des moyens d’optimiser ses ressources avec le souci d’obtenir la valeur et plus classiquement de satisfaire les intérêts de l’entreprise.
Un rôle déterminant pour les organisations
Plus aucun secteur d’activité économique n’est exempté de devoir gérer et maîtriser finement ses finances et l’utilisation de ses ressources. L’optimisation de l’allocation des investissements implique une attention toute particulière sur l’alignement stratégique du portefeuille de projets. Issue de ces investissements, le portefeuille de projets exige à son tour un pilotage pour évaluer son contenu. Ici, il n’est plus question de contraindre les chefs de projets à se conformer à un travail administratif, mais de leur fournir les outils à même de les aider à concrétiser la valeur du travail de leurs équipes et en apporter la visibilité à leurs responsables.
La responsabilité de la cellule PMO est à la fois d’analyser et de surveiller la matérialisation de la valeur des engagements pris par les projets. Il importe pour l’entreprise de la pérenniser en formalisant et en aidant la direction à décider à partir d’éléments factuels et qualitatifs via le pilotage dans le temps de la valeur du portefeuille des projets.
Quel que soit le niveau de rattachement de la cellule PMO, elle agit au cœur d’un réseau de relations humaines. Elle est à la croisée des préoccupations des différents responsables de l’entreprise. Son influence dans les relations est à la fois directive et collaborative, toujours dans le souci de servir la stratégie de l’entreprise. Chaque cellule occupe un positionnement transverse qui lui permet d’assurer une fonction qui cumule des responsabilités d’analyse, de gouvernance, et d’administration des données du portefeuille avec ou sans outils.
Elles ont pour rôle de planifier, créer, évaluer, soumettre à arbitrage les projets/programmes dans le portefeuille et de communiquer sur les priorités du portefeuille et les informations d’état des investissements en cours. Ce positionnement vise à l’obtention de la valeur des projets. Essentiellement active dans les instances et travaux de consolidation, elles font face à des exercices d’influence qui peuvent s’apparenter à du lobbying pour maximiser les affectations des directions et ce parfois au détriment des objectifs stratégiques.
Un dispositif garantissant la bonne conduite des projets
La conduite des activités PMO comprenant la planification, le contrôle et le pilotage du portefeuille implique du responsable qu’il définisse le dispositif d’évaluation en continu de son portefeuille. Elle inclue d’Accompagner les managers et les opérationnels des projets de transformation dont ces derniers ont la responsabilité. Ces activités visent à développer les capacités de l’organisation à garantir la maîtrise des projets tout au long de leur déroulement. Ces capacités sont essentielles pour porter une vision consolidée et ordonnée du portefeuille qui permet à la fois à la direction d’agir et réagir de façon approprié, mais aussi d’atteindre un meilleur alignement stratégique avec les métiers et fonctions transverses de l’entreprise.
La cellule PMO porte également une responsabilité de performance du portefeuille face à la complexité des projets à conduire. En effet, les besoins, les contraintes, contingences et dépendances émergent de toutes parts touchant tout autant le patrimoine organisationnel que le portefeuille IT. Pour cela, il lui incombe de produire une représentation de la performance du dispositif, toujours dans la perspective de concrétiser la valeur attendue des projets. Ce travail de formalisation des pratiques à mettre en œuvre et des données à analyser participe à la rationalisation des prises de décision.
Enfin dans certaines circonstances, le dispositif peut inclure la coordination Fonctionnelle/Technique des adhérences et des dépendances qui apparaissent entre les projets.
En complément, face à la multiplication des sources de données et de leur traitement en masse, la cellule PMO dispose d’un référentiel de données stratégiques pour l’entreprise. Les solutions PPM sur le marché répondent toutes à deux enjeux que sont l’amélioration de l’efficience opérationnelle recherchée (allègement du coût d’exploitation des applications et aide à la prise de décision documentée) et l’amélioration de l’efficacité organisationnelle (partage de l’information entre les entités et directions). L’apport initial de ces solutions reste l’industrialisation des activités de gestion de projet essentiel à l’amélioration de l’engagement des projets à mener. Ces solutions ouvertes sont à même de couvrir les exigences de complétude, de qualité, de cohérence et de disponibilité des données quel que soit le modèle organisationnel mis en œuvre.
Un maillon majeur pour gérer incertitude et complexité
Dernière prérogative de la cellule PMO, œuvrer à réduire le niveau d’incertitude attaché aux projets qui compose le portefeuille. Pour cela, son positionnement transverse dans l’organisation en fait le relais idéal du développement d’une culture de la gestion des risques. Toutes les activités évoquées dans le champ de la Gestion Portefeuille Projets visent à appréhender les différentes formes d’incertitude et de complexité auxquelles les programmes et directions peuvent se trouver confrontées. Réduire l’incertitude implique à tous les acteurs de poser et d’accepter de reprendre les hypothèses pour les adapter aux circonstances rencontrées.
De son côté la complexité croissante des enjeux à servir est source de contradictions au sein de l’entreprise. Elle impose à la cellule PMO de rompre les silos organisationnels et de faire preuve d’empathie envers ses parties prenantes pour parvenir à tisser des liens entre acteurs, entités, et disciplines. C’est à elle qu’il revient de multiplier les points de vue à même de relier les idées nécessaires aux décideurs.
Après plusieurs années d’accompagnement sur ces sujets, nous avons forgé des convictions fortes dans ce domaine d’intervention :
Qu’elle rende la Gestion de Portefeuille de Projet, levier de création de valeur au service de la stratégie des entreprises.
Qu’elle soit reconnue comme un relais d’information au sein du réseau d’acteurs des directions métiers et fonctions supports de l’entreprise.
Qu’elle tienne un rôle d’acteur catalyseur des capacités de l’organisation à mener à bien ses projets et activités récurrentes dans un cadre de travail connu de tous.
Qu’elle devienne le référent de l’expérience des projets métiers et technique en ce qui concerne la masse de données issues de sources multiples à traiter pour piloter les projets.
Enfin, qu’elle est un agent responsabilisant les acteurs de l’organisation dans la gestion des risques à même de réduire l’incertitude intrinsèque à toutes activités entrepreneuriales et de transformation.
Son crédo en somme : « Bien faire le travail pour faire du bon travail ».
Les transformations de l’entreprise impliquent rapidement un nombre importants de directions, une multitude de collaborateurs, internes ou externes. Les dépendances entre tous ses acteurs vont croissant et sont changeantes. Comme du temps des épopées Napoléoniennes, lorsque les aides de camp sur le champ de bataille avaient un rôle déterminant dans la victoire, la GPP, est aujourd’hui une activité essentielle pour toute direction moderne.
Souvent, on oppose la vision métier à la vision IT. Cependant, itérer des refontes de processus dans une optique d’optimisation, sans regard pour leur implémentation, revient à vouloir placer Lewis Hamilton dans une 4L : l’idée est bonne, mais il y a peut-être plus efficace.
Le premier impact de la dette technique, c’est la difficulté à faire évoluer les fonctionnalités de son système d’information.
Souvent, on prend des raccourcis en phase de cadrage pour des raisons budgétaires, de planning, ou tout simplement parce que l’on se dit que l’on fera mieux les choses plus tard… sans jamais le faire.
Cela entraine un manque de capacité à répondre aux besoins ultérieurs, notamment à tous ces nouveaux enjeux qui apparaissent régulièrement (par exemple, construire une vision 360 est compliqué sans une démarche référentiel maitrisée). Le SI devient une sorte de boulet au pieds du métier, qui l’empêche de s’adapter aux évolutions du marché. Certains chantiers sans valeur ajoutée métier, mais structurant pour les évolutions futures, ne peuvent pas être repoussé : c’est la notion de chantier « enablers ». Ce point peut devenir particulièrement préoccupant dans le cadre de projet règlementaires (les différents chantiers issus de Bâle 2, ou les sujets LAB LAT sont de bons exemples, du fait des exigences en termes de qualité des données), ou dans des contextes ou l’agilité est vitale (le secteur du Retail, par exemple, où le déploiement d’une nouvelle fonctionnalité devient rapidement un enjeux critique vis-à-vis de la concurrence).
Le deuxième impact de la dette technique est l’image que l’on renvoie aux différentes parties prenantes externes à l’entreprise, mais aussi aux internes.
Une interruption de service due à un plantage nécessitant de redémarrer les environnements de production entraine une image très négative pour le client, qui peut entrainer un désengagement en cas de fréquence trop élevée (pensez à la dernière fois où votre connexion internet personnelle ne fonctionnait plus, et au stoïcisme dont vous avez su faire preuve à ce moment). En interne, cela entraine un désengagement progressif des équipes, du fait de tâches répétitives à très faible valeur ajoutée, du sentiment de faire systématiquement des solutions dégradées, ou à la survenue fréquente d’incidents de production. Ces points génèrent de la frustration, dans le sens où ils donnent le sentiment que la qualité n’est pas le souci de l’entreprise (surtout lorsqu’on leur demande de prioriser un sujet, pour au final dénaturer le résultat de l’étude). Si cela entraine un turn over dans vos équipes, le sujet est préoccupant. Si vous êtes en difficulté de recrutement, cela peut devenir critique, d’autant que les premières victimes du turn over sont les hauts potentiels, qui souhaitent être pilotés par la qualité et la richesse des sujets.
Le dernier impact de la dette technique que j’évoquerai dans cet article est budgétaire.
En effet, toute dette doit se rembourser un jour, et entraîne des coûts récurrents d’ici là. Cela va générer des coûts projets plus importants lors des évolutions, ou des actions humaines pour corriger des erreurs issues de ces dettes (par exemple, le rapprochement des chiffres comptabilité / gestion réalisé manuellement, faute de chaîne de traitement fiable). N’oublions pas aussi ces applications dont le décommissionnement est acté, mais jamais terminé (ce qui entraîne de nombreux coûts, mais une augmentation significative de la complexité du SI du fait de la parallélisation des chaines).
Au final, cela se traduit par des coups de canif dans votre budget projet, sous forme de coûts de runs importants, ou de chiffrages projets plus importants que prévu (matérialisés par le classique « La DSI coûte trop cher »).
Il y a bien entendu beaucoup d’autres raisons qui devraient nous pousser à ne pas négliger la dette, cependant, ces 3 points sont des enjeux que l’on retrouve dans toutes les DSI : Agilité, Expérience utilisateur / qualité de service, et maîtrise budgétaire.
Dans un prochain article, nous allons parler de la gestion de la dette dans le cadre des projets Agile.
Tout comme une dette financière choisie intelligemment peut être synonyme de succès financier, toutes les dettes techniques ne sont pas nécessairement handicapantes pour l’entreprise, et peuvent aussi être un levier de croissance rapide. Cela se vérifie tout particulièrement lorsqu’on ajoute un nouveau système pour prendre des parts de marché : la dépense présente pour répondre au « time-to-market » est faite dans l’espoir d’un gain futur.
Attention cependant, tout comme les dettes financières non maîtrisées, les dettes techniques peuvent devenir un « poids mort » pour l’entreprise. En cas de difficultés trop importantes, elles accaparent les équipes et engendrent une évolution défavorable du rapport Run / Projet. Cela est synonyme de baisse dans la capacité à livrer de nouvelles fonctionnalités, mais aussi souvent de démobilisation des équipes, voire de turn over. Dans les cas extrêmes, par exemple pour les entreprises avec des ressources limitées, cela peut devenir léthal si la direction n’est pas vigilante à cet indicateur Run/Projet.
C’est pourquoi dans ce premier article, nous avons identifié 3 types de dettes IT et 3 parades pour les traiter :
Dette technique opportuniste et plan de remédiation
Un concepteur sait, en général, qu’il y a deux façons de créer une fonctionnalité : la bonne ou la rapide. La manière rapide n’est pas nécessairement la mauvaise, car elle consiste à ne pas faire de sur-qualité. Cependant, l’économie peut très bien avoir été faite au détriment de la scalabilité : la bonne idée d’un jour se révèle être un choix non pérenne. Bien souvent le concepteur est contraint de faire ainsi pour réduire le time-to-market.
Ce choix est parfaitement acceptable, mais il faut l’accompagner d’un plan de remédiation, pour assurer la pérennité du nouveau système une fois que celui-ci en sera en production. Dans le cas contraire, les dettes techniques vont s’accumuler petit à petit, ce qui entraînera inexorablement la baisse de la qualité de service pour les utilisateurs, la frustration des équipes en charge de la maintenance applicative et l’accroissement des coûts d’exploitation du fait des incohérences techniques et fonctionnelles à corriger continuellement.
Ce type de dette doit donc être tracé, pour permettre des actions de remédiation. En parallèle, un sponsor / product owner doit être tenu responsable de l’évolution de la dette technique sur son périmètre, et donc être objectivé sur ce sujet. La cohérence n’est pas un artifice.
Dette technique liée à l’innovation et pilotage des exigences
Dans le monde de l’IT, de nouveaux patterns et technologies apparaissent sans cesse. Il en va de même pour les usages.
Un choix de conception, à un moment donné, peut être remis en cause soit par une évolution des usages métiers, soit par l’apparition d’une nouvelle technologie entraînant une obsolescence fonctionnelle.
Ce type de dette finit toujours par apparaître qu’on le veuille ou non. Il est donc important de sensibiliser le sponsor / product owner à la nécessité de suivre la satisfaction des exigences sur son périmètre, afin de déclencher des actions de remédiation le cas échéant.
Dette technique « endémique » et vastes chantiers de modernisation
Ce type de dette est relatif aux vieux systèmes, sur lesquels ont été empilées au fur-et-à mesure des demandes d’évolution de nouveaux traitements complexes, sous forme de « verrues », jusqu’à créer une complexité telle que les systèmes deviennent impossibles à maintenir / faire évoluer, sans parler du turn over, entraînant inexorablement une amnésie informatique.
Dans le cas de fonctionnalités critiques pour le métier, cela constitue un risque opérationnel pour l’entreprise.
Ce type de dette doit être évité autant que possible, et faire l’objet de vastes chantiers de modernisation. Souvent, cela implique un remplacement pur et simple du système par un nouveau, plus adapté, et surtout mieux conçu.
Il existe aussi d’autres types de dettes, notamment celles créées inconsciemment …
Dans tous les cas, un système de classification des dettes techniques va permettre de les identifier et de sensibiliser les donneurs d’ordre, et leur proposer des plans de résolution adaptés :
Plan de remédiation pour favoriser la scalabilité et la pérennité au fil de l’eau
Pilotage des exigences pour accompagner l’évolution technologique
Vastes chantiers pour faire face à la dette « endémique »
Le sujet vous intéresse ? Restez à l’écoute, dans un prochain article, nous discuterons des différents impacts de la dette technique sur l’entreprise, et pourquoi cela n’est pas qu’une question « d’informaticiens ».
Dette technique : 3 types, et 3 approches pour la maîtriser
