Piloter un développement logiciel sur-mesure

A. GHAMRI, janvier 2021

Il n'y a pas une plus grande gageure pour un DSI que de recevoir une demande de développement de logiciel sur-mesure. Non seulement, il n'est que rarement en manque de challenge avec toute la complexité des systèmes d'informations qu'il gère au quotidien, de plus, le développement sur-mesure est connu pour être un gouffre financier et un fardeau difficile à maintenir. Aujourd'hui on parle de big-data mais on oublie une autre facette des SI qui n'est pas moins big. Le big-code.

image/svg+xml Besoin Budget Spec Planning Suivi Recette Révision Appel d'offre / Nomination Evolution
Cycle en V. Cliquez pour sauter au paragraphe désiré.

Mais il y a pire pour un DSI. C'est de voir ses collègues se débrouiller par eux-mêmes et se servir dans la jungle d'Internet. Il ne serait pas très fâché pour une simple macro partagée sur un sharepoint interne, mais si on a fait appel à un formulaire typeform, une sheet airtable, un google drive et le tout mijoté dans Zapier, cela devient beaucoup moins amusant ! On appelle ca le shadow-IT.

La meilleure façon de gérer un développement sur-mesure et de ne pas le faire. Cependant, si le besoin prévaut, voici quelques points clés pour en assurer un bon pilotage.

0. Vue générale

Par analogie au très classique cycle en V du développement logiciel, il convient aussi de mettre en V le cycle de sa gestion de projet.

Le cycle en V donne deux perspectives intéressantes :

  • Le raffinement
  • Chaque étape de la descente enrichit un peu plus le projet et est une base pour les étapes suivantes.
  • La dualité
  • Les étapes antagonistes sont complémentaires. En effet, chaque étape de la branche montante est mesure de sa jumelle sur la branche descendante.

1. Le Besoin

C'est le point de départ de tout projet, qu'il faudra aborder avant tout autre chose. On commence par questionner la nature du besoin et sa justification en challengeant le porteur du projet qui est dans la plupart des cas porté par l'enthousiasme de son idée. Même s'il est expert dans sa discipline, il peut avoir une vision biaisée qui tend à complexifier le problème.

Ensuite, on cherchera dans l'organisation si on a déjà répondu à des demandes similaires ou si on dispose déjà de moyens susceptibles de répondre à ce nouveau besoin parfois avec une simple déviation.

Les manuels de gestion de projet vous dirons tous que le questionnement du besoin ne s'arrête jamais tout au long de la vie du projet. Toute décision est à ramener à celui-ci.

1.1 Evolution du besoin

Un besoin évolue dans le temps, c'est pour cette raison qu'il faut se donner un maximum de flexibilité et d'ouvertures. Une solution doit être évolutive et facilement modifiable afin de rentabiliser votre investissement sur le long terme.

2. Le budget

Combien en est-on prêt à mettre sur la table ?.. Ce n'est pas tout à fait la bonne formulation. Cette étape n'est pas aussi objective qu'on puisse le croire, on ne peut pas définir un budget ex-nihilo. Il nous faut une référence. Les prix pratiqués dans le secteur et le marché ? Les factures/devis passées pour des commandes similaires ? C'est seulement à partir de ces données et à partir d'une estimation de la nouvelle charge qu'on peut définir une fourchette et décider si oui ou non, on lance une consultation et jusqu'où on pousse le curseur dans la fourchette.

Les prestations de développement sont souvent évaluées en jour/homme (ou TJM) qui varient suivant l'expérience du prestataire (400 eu/j en moyenne pour un freelance en France). Cependant, certaines structures tendent à travailler en unités d'œuvres.

Une unité d'œuvre (UO) est un jour/homme moyenné sur des ressources hétérogènes et mutualisées. En effet, une ESN peut utiliser des ressources variées :

  • Equipe de développement locale ou offshore (inde, europe de l'est...)
  • Des ressources qui ne sont pas des DEV : gestion de projet, support...

En plus, ces ressources sont généralement mutualisées. Ils travaillent sur différents projets pour différents clients.

L'UO est donc une moyenne qui simplifie le calcul et qu'il faut voir comme une unité de mesure de la charge d'un livrable plutôt comme une métrique du temps passé.

2.1 Révision

Un budget se révise aussi bien à la hausse comme à la baisse. Un développement est par essence non-déterministe. C'est une exploration. On peut rencontrer des difficultés et des imprévus, comme on peut dégager un excédent.

Il faut donc se donner une marge au départ et réajuster en fonction de l'excercice.

Il y a aussi la question existentielle : est ce qu'on a eu pour votre argent ? Ou formulée autrement, est ce que nous nous sommes pas fait berné ?

C'est une question classique à laquelle académiques comme industriels ont tenté d'apporter une réponse. Ca va du comptage naïf du nombre de lignes de codes (CLOC) jusqu'à des formules savantes basées sur la complexité cyclomatique, le volume d'entrée/sorties...etc. Aucune métrique n'a été concluante.

Il est inutile de réifier une production intellectuelle à sa forme textuelle. Le code n'est qu'un dérivé qui dépend de plusieurs facteurs très variables et qui n'est pas corrélé du moins par sa volumétrie à la valeur créée.

La valeur d'une production logicielle peut mieux être approchée à l'usage. C'est-à-dire par la mesure du nombre et la qualité des fonctionnalités, le nombre de pages et leurs richesses en contenus, leur ergonomie...etc.

Cependant, on peut (et on doit) évaluer la performance, la sûreté et la sécurité d'un code. Ces caractéristiques font partie intégrante de la valeur d'un logiciel.

3. La spec.

Une fois le besoin et le budget définis, on prépare notre spécification. C'est le moyen de communiquer son besoin au monde extérieur (ou en interne si vous avez une équipe DEV intégrée). Une bonne spec doit être :

  • Non-ambiguë
  • Qui se prête le moins à l'interprétation et à la devinette.
  • Modulaire
  • Composée de sous-ensembles consistants et les plus indépendants possible.
  • Testable
  • Qu'on peut évaluer et tester pour dire si oui ou non, elle est satisfaite.

Vous pouvez toujours écrire un cahier des charges formel avec des exigences bien encadrées et formulées comme des textes juridiques. Cependant, cela serait un over-kill pour des projets de petites et moyennes tailles.

En plus de vous prendre beaucoup de temps à son élaboration en amont, ce format n'est pas toujours efficace.

Une meilleure approche pour exprimer son besoin est de le définir par :

  • L'interface ou l'expérience utilisateur
  • Je dois avoir une fenêtre par ci, un bouton par là, une alerte...etc, quitte à la dessiner sur un Powerpoint
  • Le cas d'usage
  • Quand je clique ici, il se passe cela, un e-mail est envoyé à X...etc.

L'intérêt de cette approche est de pouvoir découper sa spec en lots de cas d'usages (avec les interfaces associées) et de construire une roadmap de développement et intégration progressive. Vous pouvez de plus adopter une approche agile avec des livraisons intermédiaires qui permettent à vos équipes de commencer très tôt à tester et utiliser le produit.

4. Planning

Corollairement au paragraphe précédent, le planning peut être construit de façon à prioriser les lots fonctionnels les plus importants ou plus urgents. Vous pouvez également en paralléliser certains pour accélérer la recette finale du projet.

4.1 Suivi

Le découpage en lots offre aussi l'occasion de mettre en place des checkpoints réguliers pour superviser les coûts, la performance du prestataire, clarifier la spec, corriger les bugs,...etc.

5 Appel d'offre / Etude / Selection

Si vous avez bien cadré les étapes précédentes, celle-ci ne devra pas vous poser beaucoup de problèmes. Vous êtes clair dans votre vision des choses et vous ne pouvez que l'être avec vos prestataires. La seule chose à dire ici, c'est l'équilibre dans le choix.

La bottom-line (l'addition) n'est pas tout. Evaluez la performance et la flexibilité du prestataire. Rappelez-vous que les besoins évoluent et qu'un projet, par définition, ne manque pas de surprises.

Inscrivez-vous à notre newsletter

Vous serez informé(e) de nos articles et nouveautés.