Mener un projet numérique sans la DSI

Aider mes équipes à prendre en charge leur avenir numérique
 

Avis d’expert par Arcady Ahmed, Responsable Marché Finance & Services chez Oxalide

 

La course à l’armement sur les sujets digitaux est entre les mains des métiers. Le rythme business n’est pas le rythme des Directions Informatiques. Le « Time To Market » du web appelle des méthodes nouvelles et des prises de risques. De plus en plus, les projets web sont financés par les BU métiers et les directions de l’innovation.
Mais respectivement, la DSI reste le grand garant de la sécurité de l’entreprise, d’autant plus avec la mise en œuvre très prochaine du RGPD. Sachons garder à l’esprit le rôle d’approbateur général de la DSI, qui dispose tout à la fois d’une vision large de la culture de l’entreprise et de la politique informatique à respecter.
Gérer un projet numérique au rythme du business est donc un projet sans DSI au quotidien. Pour y parvenir, voici dix suggestions classiquement constantes d’un succès.
 

Recrutez votre prestataire comme vos collaborateurs

Les niveaux d’exigence varient amplement d’un projet web à l’autre, en fonction de l’attendu final, de la criticité business et du porteur du projet. Un site wordpress d’information sur les produits de l’entreprise, adressant une problématique RSE, n’affiche pas le même degré d’engagement qu’une start-up au sein du groupe chargée de faire la preuve de son succès en un an. A chaque projet correspond donc un prestataire qui saura partager avec l’équipe l’ambition et les objectifs qu’elle affiche. Il doit partager avec elle les facteurs clés de succès, et témoigner des méthodes qui y conduiront.
 

Peu importe la destination, seul le voyage compte

Cela ressemble à l’axiome d’un coach en développement personnel et pourtant, à chaque nouveau projet web, le chemin à parcourir est bien souvent plus important que le résultat à obtenir. Souvenez-vous de vos expériences précédentes : vos livrables sont-ils identiques à votre cahier des charges initial ? Si non, est-ce dû à l’évolution de votre roadmap ou encore à une proposition de vos partenaires ? Il y aura toujours des cahiers des charges à suivre et des objectifs à tenir, mais il faudra savoir éviter l’écueil de la frustration et des blocages qu’ils peuvent engendrer. D’une part, le produit attendu peut se révéler être une mauvaise réponse, seule l’expérience du produit peut le dire. D’autre part, à trop cadrer votre prestataire, vous prenez le risque de brider son élan d’innovation. C’est pourtant sur cette qualité que vous l’avez, entre autres, sélectionné. Préférez une vision générale du projet et procédez par itération. Laissez de la place aux bonnes surprises.
 

Ne négligez pas l’hébergement et l’infogérance

Réfléchir à l’hébergement en mode pompier est le signe d’un manque de préparation qui peut conduire tout droit à l’échec d’un projet. Un infogéreur n’est en mesure de tenir ses engagements que s’il entre suffisamment tôt dans le circuit. Il saura en outre mieux définir l’architecture utile et cela en peu de temps. Une équipe efficacement constituée réunira donc un représentant métier, un développeur, un expert en UX design et un architecte DevOps, pour une proposition cohérente de A à Z.
 

Montez une équipe cross fonctionnelle

Justement. Fer de lance de tout projet web, que l’on retrouve évidemment à chaque étape, la fameuse Pizza Team ne porte ce nom que parce qu’une pizza (grande taille) doit pouvoir nourrir toute une équipe. Bref, c’est une équipe réduite à sa plus simple expression qui évite toute déresponsabilisation et son corollaire, l’inertie. C’est une équipe certes petite mais qui couvrira toutes les compétences utiles.

Au maximum, dans cette feature team, on retrouvera un product owner ou chef de projet, un lead developer, un architecte, un responsable de la sécurité, un UX ou directeur artistique et un scrum master éventuellement si l’équipe choisit cette méthode. Cela sous-entend de tordre le cou à tout ce qui pourrait ralentir la prise de décision de l’un ou l’autre membre de l’équipe.
 

Ayez une approche agile

Il est inutile de tergiverser, l’agile est un standard pour travailler correctement sur un projet web, compte tenu de la vélocité que cela exige. C’est ainsi que l’on parle de minimal valuable product,  le produit minimum, devant fonctionner parfaitement, pour être livré, exploité et surtout évalué sur sa capacité à répondre aux objectifs attendus. Afin d’illustrer ce propos, imaginons que l’attendu soit un véhicule pour se déplacer plus rapidement. La première itération proposera peut-être alors un skateboard afin de répondre au besoin primaire. La deuxième, sans doute une trottinette et ce, jusqu’à la voiture.

Le MVP fait peu, mais il le fait bien. Il est disponible rapidement et permet tout aussi rapidement de décider de l’orientation à prendre ensuite. C’est l’exact opposé du cycle en V. Oubliez le cycle en V.
 

Partagez avec tous des KPI communs

Et ce dès les premiers échanges. Concrètement, si le métier se fixe X milliers de nouveaux utilisateurs du service dans 6 mois, c’est autant un objectif qu’un KPI,  que tous les acteurs du projet doivent connaître. Cela vous paraît très éloigné des préoccupations d’un développeur ? d’un intégrateur ? d’un expert UX ? Bien au contraire, c’est un jalon, qui contribuera à façonner l’état d’esprit des membres de l’équipe, et qui aidera chacun à s’extraire de ses objectifs individuels. Il y a souvent quelques surprises à la livraison d’un projet, que l’on peut aisément éviter en communiquant plus sur les caractéristiques attendues.

Il va de soi que pour partager utilement, on utilisera des outils de communication identiques : gestion de projet, tchat, monitoring… JIRA par exemple est une solution de gestion de projet classiquement utilisée par les développeurs et qui fait aujourd’hui le pont entre tous les acteurs d’un projet web, dont les métiers, qui se l’approprient aisément.
 

Optez pour le DevOps

DevOps, c’est accepter qu’un projet web évolue. C’est dans la nature d’un projet web que de changer. Avec le DevOps, les devs industrialisent leur travail en partageant des outils d’intégration continue, de livraison en continu et déploient plus rapidement de façon fiable et automatisée. Ceci en limitant les risques sur la production avec un monitoring partagé.

Toute évolution d’une roadmap réalisée par les développeurs doit pouvoir être absorbée par les ops’ (admin systèmes) sans douleur, sans que cela ait d’impact sur la manière d’opérer le service. Ce qui marche dans un environnement d’intégration doit marcher dans un environnement de production, c’est-à-dire chez l’utilisateur final, de la même façon.
 

Ouvrez votre porte au cloud public

Maintes fois mis en avant, le grand avantage du cloud public est la flexibilité qu’il apporte. Disposer de la puissance et de la performance utile, ni plus, ni moins, pour l’exploitation de son service, va au-delà d’une simple question de confort. C’est se donner les moyens de rester en rythme avec l’évolution de son marché, que l’on sait particulièrement versatile sur le web. Mais plus généralement, c’est aussi une nécessité pour innover.  Les services proposés par les Cloud Provider exigeraient en interne des efforts trop coûteux. Un service de Big Data à la demande, un service de Push Notification prêt à l’emploi, une base de données auto-gérée… ne seront jamais livrés par une DSI en un clic comme sur un cloud public.
 

Pensez votre sécurité by design

Le RGPD aura de nombreux effets positifs notamment dans la mise en œuvre de bonnes pratiques. Le principe de privacy by design notamment devrait être un coup de pied dans la fourmilière des projets web à la sécurité pensée en dépit du bon sens ou pour être précis, pensée à l’étape de la mise en production, autant le dire, bien trop tard.

La sécurité est l’affaire de la DSI et s’il ne fallait donner qu’un seul conseil, ce serait celui de la consulter  dès les premières étapes d’un projet, quel qu’il soit. Autant pour la paix dans l’entreprise que pour des raisons de coût supplémentaire et de délais.
 

Communiquez sur vos facteurs clé de succès

En tant que chef de projet, il est indispensable de marteler ses objectifs à sa feature team, mais également à sa direction et à ses partenaires. Voire à tous ceux qui ne sont pas vraiment concernés au départ, car ce n’est jamais du temps perdu. Ce qui peut être perçu comme un succès par les uns ne le sera pas forcément par d’autres. Tout dépend du degré d’information de chacun. Pour partager sa joie d’avoir réussi, ou continuer d’être soutenu, la roadmap (notamment business) et ses évolutions doivent être connues de tous.