De nos jours, le cadrage d’un projet IT n’est pas une mince affaire… En effet, nous avons vu précédemment que l’IT devient de plus en plus compliqué.
Les utilisateurs ont certes gagné en maturité. L’IT s’est diffusé dans toutes les couches de la société et une offre logicielle pléthorique tend à combler tous les besoins. La combinaison de ces différents facteurs ne rend pas pour autant le choix plus facile.
Pourtant, si on ne veut pas « faire n’importe quoi », il faut se poser les bonnes questions. Les lignes qui suivent devraient vous apporter, je l’espère, quelques pistes de réflexion.
Cadrage Projet IT : deux dimensions à prendre en compte
Tout examen d’une solution repose sur deux critères.
Le premier est celui de la dimension stratégique du besoin ou du projet IT et le deuxième est celui de sa criticité.
La dimension Stratégique
C’est la première question qu’on doit se poser pour réussir son cadrage de Projet. Ce projet répond normalement à une attente. Qu’il s’agisse de répondre à un besoin, de modifier un applicatif, ou d’innover dans la façon d’adresser une activité métier, il faut se demander le niveau stratégique de la dite activité.
Le sujet est-il différenciant pour mon organisation ? Est-ce qu’il apporte un vrai « impact » dans ma relation avec mes clients? dans la façon dont je délivre mes biens ou services au marché ?.
Si je prends deux exemples je serai peut-être plus clair. Si par exemple, vous êtes un e-commerçant, votre site marchand sera forcément stratégique pour vous. De même, les actions liées au référencement, ou même peut-être des projets liés aux activités de négoce (Achat/Vente, stratégie prix, etc…).
A l’inverse, votre outil bureautique, la gestion de vos notes de frais ou encore votre logiciel de suivi des congés… relèveront plus de la commodité. Aucun intérêt stratégique là-dedans.
La dimension Criticité
L’autre question qu’il faut se poser, nous est amenée par le Cloud, devenu incontournable aujourd’hui. Il faudra forcément se poser la question soit d’un Cloud Public, soit un Cloud Privé ou éventuellement On Premise (sur site), même si cet usage tend à se raréfier.
Comment déterminer la bonne option?
Pour placer son projet sur ce second axe, il faut se poser la question quant à la délégation de la gestion et de la responsabilité de ce dernier. A quel point le service est-il critique pour moi?
Par exemple, si je ne peux me permettre de déléguer la responsabilité du périmètre en question (ex. données sensibles) alors il faudra sans doute que j’opte en priorité pour un cloud privé ou du « on premise ». Si je veux m’assurer un taux de disponibilité très élevé pour une application, il faudra que j’en conserve la responsabilité. Ou au contraire que je la délègue à un cloud public qui aura des niveaux de service bien supérieurs à ceux que je pourrai assurer en interne.
Comment prendre en compte ces deux dimensions dans votre cadrage de projet IT?
Les deux axes permettent de s’y retrouver dans l’offre pléthorique sur le marché des logiciels et/ou des choix technologiques.
La stratégie détermine le niveau de « custom »
L’axe stratégique va ainsi permettre d’opter entre deux extrêmes:
- d’un côté le logiciel « figé », c’est à dire qu’à part un peu de paramétrage, on ne peut rien y changer
- et à l’autre bout, le développement « custom », c’est-à-dire la réalisation de code « à façon », pour répondre spécifiquement à un besoin
Entre les deux, il y a d’autres alternatives, avec des logiciels plus ou moins modifiables, paramétrables ou intégrables.
On va donc avoir,
- pour les solutions qui relèvent de la commodité, une application « sur étagère », standard à laquelle on ne changera rien (ex. votre suite bureautique, un logiciel de demande de congés),
- pour les solutions assez communes mais que je dois adapter à mon contexte, des solutions paramétrables (ex. Solution de BI, logiciel Comptable ou RH, ERP…) voire des des plateformes low-code ou no-code qui offrent un degré de personnalisation important pour un coût minimal,
- ou encore, des périmètres « stratégiques » sur lesquels il est important de se différencier de la concurrence, et donc on acceptera un niveau de « développement custom » plus important, même si le projet IT issu de ce cadrage est plus long et plus coûteux qu’un assemblage de briques déjà présentes sur le marché. Cela vaudra le coup et le coût de le faire pour se doter d’un « facteur clé de succès » sur le marché.
Prise en compte de la criticité
Quand on prend en compte la deuxième dimension, évoquée plus haut, celle de la criticité avec la différence entre Cloud Public et Cloud Privé (ou éventuellement « On premise »), cela permet de positionner les différents projets IT (ou applications correspondantes) les uns par rapport aux autres.
Autres éléments à prendre en compte dans le cadrage d’un projet IT
Si les deux points cités plus haut sont essentiels, il existe aussi des facteurs secondaires à prendre en compte.
D’abord il faut regarder si on dispose des compétences en interne pour mener à bien le projet. On peut avoir des collaborateurs à staffer ou à faire monter en compétences. Si ce n’est pas le cas, il faudra prévoir des recrutements ou, à minima, le concours d’un prestataire. A l’inverse, des équipes internes « à occuper » sont une contrainte à intégrer.
On doit aussi tenir compte de l’historique du parc applicatif (besoin de cohérence ou au contraire de renouveau). Il faudra notamment être sûr de pouvoir faire communiquer toutes les applications entre elles.
De plus, il faut intégrer « l’utilisabilité » et la cohérence pour les utilisateurs. En effet, il sera difficile de proposer aux utilisateurs une « expérience » et une ergonomie complètement distincte de leurs habitudes.
Enfin, (last but not least!), le cadre réglementaire doit également être pris en compte : les données personnelles soumises au RGPD, les données médicales ou encore les informations bancaires ne sont pas des données comme les autres. Elles doivent être traitées de façon particulière.
Impact de la décision
Quels que soient les choix effectués, on s’aperçoit que tous les SI ont tendance à être de plus en plus « éparpillés ». Pour que cette évolution naturelle ne devienne pas un handicap pour l’entreprise, elle doit veiller à la mise en œuvre de deux grands principes. D’un part, s’assurer d’une bonne communication entre les différentes applications. Le SI doit être ouvert et parfois même recourir aux microservices. Ils cumulent différents avantages : simples à remplacer, dédiés une tâche spécifique (facturation, chaîne logistique, etc.). Et aussi une architecture symétrique qui garantit des échanges fluides entre plusieurs entités communicantes.
D’autre part, et cette partie reste la plus complexe à appliquer, il faut accepter l’incertitude et la remise en cause des choix. En effet, le monde de l’IT change à une vitesse phénoménale : rien n’est définitivement figé. La souplesse, la résilience et l’adaptabilité du SI sont des qualités essentielles pour le faire évoluer et éviter que sa complexité croissante finisse par peser sur la compétitivité de l’entreprise.
Les sujets qui m’intéressent le plus sont Data, Organisation et Temps Réel !
N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour partager nos actualités!
Andrea
