CONDUIRE UN PROJET NUMÉRIQUE (COMPLEXE OU PAS)
L’article met à bas les 2 mythes suivants :
- conduire un projet numérique, je sais faire, car j’ai un portable, une box, je suis actif sur Discord, Twitch, TikTok, donc je connais le numérique ;
- conduire un projet numérique nécessite d’être Black Belt Lean Six Sigma, certifié PgMP®, SAFe®5.0 car la 4.6 est « has been » !
Mon expérience, tant au Ministère qu’en formation continue, et les discussions que j’ai pu avoir en tant qu’ancien président de l’AFIS (Association française pour l’ingénierie système) et initiateur de la création du GINUM (groupement des intervenants du numérique pour la défense, la sécurité et les enjeux d’importance vitale), m’ont montré que quelques principes clés vous permettent de réussir, et surtout de ne pas échouer. Tout le monde vous dira qu’ils sont évidents. Mais personne quasiment ne les applique systématiquement. D’où d’ailleurs les échecs fréquents, en particulier dans le domaine des grands projets numériques, soulignés décennie après décennie par les enquêtes (Standish Group, rapport Chaos) et les divers rapports de la Cour des comptes, du Sénat, etc. Sans polémiquer sur l’exactitude des chiffres, près de 2/3 des projets sont en difficulté, le reste se répartissant entre échecs patents et réussites claires…
Ton projet s’inscrit dans la stratégie de ton entreprise !
C’est une dure constatation : notre activité se fait au sein d’un projet et au sein d’une entreprise (privée ou publique, grande, moyenne ou petite), donc il y a des contraintes, des directives, des règlements, des normes, des lois à respecter !
Et le numérique n’est pas l’anarchie ou la place à la créativité folle des geeks. Toute entreprise a une gouvernance qui donne un cadre général à respecter, pour l’usage de solutions, et de facto pour leur conception et leur développement.
C’est ainsi que doivent être pris en compte le respect du RGPD (Règlement général sur la protection des données), les obligations d’accessibilité numérique du RGAA (Référentiel général d’amélioration de l’accessibilité), l’application de la politique des données propre à l’entreprise, les exigences de sécurité des systèmes d’information, etc. Eh oui, cela impose des choix, cela empêche de faire des choses, cela coûte, cela prend du temps : conduire un projet, c’est aussi devoir respecter des règles. De même que quand on conduit un véhicule, il y a un code de la route et d’autres usagers sur la route…
Ton projet doit être utilisé par des utilisateurs !
La (seule) finalité qu’il faut avoir en ligne de mire, c’est la valeur fournie aux utilisateurs qui vont utiliser les produits du projet ou consommer les services qu’il met à disposition. Comme le disait Thomas Edison, la vraie valeur d’un produit ne réside pas dans ce qu’il est, mais bien dans ce qu’il apporte. Ce qui compte, ce n’est pas le prix de l’ampoule, c’est celui de la lumière.
Ce qui veut aussi dire que l’on a identifié les utilisateurs, ou les classes d’utilisateurs… Et par voie de conséquence, il est essentiel de s’assurer que toutes les conditions sont remplies pour que les extrants du projet soient disponibles dans la durée. Être homologué, qualifié, répondre à un besoin fonctionnel, sont des conditions nécessaires mais pas suffisantes : les scénarios d’usage sont clés pour démarrer, car la mise en situation imaginée permet ab initio de ne pas bâtir des châteaux en Espagne.
Dit autrement, les questions clés sont : pourquoi ? pour qui ? quelle valeur et quels usages sont attendus ? et par qui ? Et la question à ne pas poser est… comment ?
Ton projet doit disposer d’une équipe projet et de ressources adaptées aux objectifs !
Les ressources comprennent les ressources humaines, avec les compétences adaptées, ainsi que les ressources budgétaires. On ne doit donc pas démarrer un projet sans budget prédéfini et sans équipe projet ! et cela sur la durée de vie prévue, donc en ne s’arrêtant pas à la réception du premier livrable…
Je ne peux pas donner de nom de projet, mais j’ai en tête une situation où l’idée était d’externaliser la conduite de projet via une assistance à maîtrise d’ouvrage (à qui évidemment on ne sait pas quoi demander si ce n’est qu’elle doit conduire un projet non défini et sans budget… le temps qu’on trouve des ressources internes…).
Ton projet s’inscrit dans un environnement !
Il faut donc identifier et entretenir les interactions avec d’autres projets, avec d’autres parties prenantes. Cela évitera les sempiternelles remarques du style : « j’ai fait réaliser les fournitures demandées, mais ce sont les autres qui n’ont pas fait les modifications pour que mon truc marche », ou alors « j’ai réalisé tout ce qui était demandé, mais l’hébergeur est mauvais et ne sait pas faire marcher mon truc génial »…
En fait, quel que soit le projet – mais c’est d’autant plus important pour le numérique, car les temps de cycle associés se chevauchent beaucoup plus rapidement –, il y a 4 parties prenantes clés à gérer :
- le client (ou sponsor : il donne le budget),
- l’usager (ou consommateur),
- l’équipe en charge du développement (ou maîtrise d’œuvre de la réalisation : elle développe, réalise les produits et les services),
- l’équipe en charge de la maintenance (ou de l’opération : elle s’assure que l’usager pourra utiliser dans la durée produits et services, faisant les actions correctives ou préventives nécessaires).
Ton projet doit vivre !
Cela rime avec « être utilisé », cf. supra, mais insiste sur une certaine pérennité nécessaire : en effet, un besoin ne se décrit pas uniquement fonctionnellement, il doit être décrit en termes d’usages, d’attendus vis-à-vis des utilisateurs (ou consommateurs), et tout cela pendant une certaine durée. Ce dernier point est essentiel, car on ne développe pas un projet – qu’il soit numérique ou pas d’ailleurs – de la même manière selon qu’il doive être viable pendant des mois, des années ou des décennies !
La notion clé est donc celle de maîtrise du cycle de vie, prenant en compte le MCO/MCS (maintien en condition de sécurité) au fur et à mesure des évolutions logicielles, du produit, de son environnement d’hébergement, de l’environnement avec lequel il peut être amené à interagir. Donc, au niveau de la conduite de projet numérique, il convient de prendre en compte ces aspects techniquement, financièrement, calendairement : en particulier, ne pas oublier de définir des feuilles de route, incluant les technologies et leur obsolescence.
Ton projet n’est pas un long fleuve tranquille !
Comme dit un proverbe chinois : « pour pouvoir contempler un arc-en-ciel, il faut d’abord endurer la pluie ».
En effet, les utilisateurs changent d’avis, d’habitudes… L’environnement lui-même est changeant : encore plus quand un projet prend du retard (oui, cela arrive trop fréquemment !). Les risques évoluent aussi, du fait de nouvelles menaces (et le numérique nous en fait découvrir chaque jour de nouvelles, d’autant plus à prendre en compte qu’elles utilisent les faiblesses des utilisateurs en matière d’usage du numérique), mais aussi de nouvelles exigences. Et il n’y a pas toujours le bon budget au bon moment.
Bref, il faut être réactif, adaptable aux changements, en d’autres termes : agile.
En conclusion
Sois prêt au pire, et vois la forêt et pas les arbres : c’est l’objectif final, la valeur rendue, qu’il faut garder à l’esprit, et pas se focaliser inutilement sur certaines techniques ou technologies.
Et surtout, il ne faut pas démarrer un projet sur une simple idée technique, alors que l’on ne sait pas ce que réellement il faut faire, pour quand, pour qui, et comment on mesurera l’atteinte des attendus.
Contrairement à certaines utopies, ce n’est pas une réalisation « en mode agile » (buzzword que l’on s’envoie trop souvent en réunion en ironisant sur les chefs de projet utilisant cycle en V et processus en cascade, voulant connaître le besoin avant de démarrer !) qui va pallier l’absence de cap et de trajectoire…
Aucun commentaire
Vous devez être connecté pour laisser un commentaire. Connectez-vous.