Le déroulement d’un projet logiciel, du devis à la livraison

L’une des premières questions d’une organisation qui veut faire développer un logiciel porte sur le déroulement. Quand verra-t-elle quoi, qu’attendra-t-on d’elle, à quel moment le travail sera-t-il considéré comme terminé.

Dans cet article, je décris les étapes par lesquelles passe un projet, du premier rendez-vous à la maintenance. Les étapes n’ont pas la même durée dans chaque projet. Pour un petit projet, plusieurs tiennent en une seule réunion. Mais aucune n’est sautée, car une étape sautée revient sous forme de surprise à la fin du projet.

Le premier rendez-vous

Au premier rendez-vous, nous ne parlons pas de prix. Nous cherchons à comprendre ce que l’on veut faire, comment le travail se fait aujourd’hui et ce qui doit changer. Qui va l’utiliser, quelles données seront traitées, avec quels systèmes il faudra échanger.

À la fin de ce rendez-vous, il nous arrive de dire qu’un logiciel sur mesure n’est pas nécessaire. Si un produit existant fait l’affaire, le dire dès le départ fait gagner du temps à tout le monde.

Le cadrage

Si le besoin n’est pas clair, nous proposons une courte phase de cadrage. Quelques ateliers, un examen des systèmes et des données existants, la description du processus métier étape par étape. Le livrable du cadrage est un document écrit : périmètre, rôles utilisateurs, intégrations, données, risques connus et inconnues.

C’est la phase la moins chère du projet, et celle qui fait économiser le plus. Corriger un besoin mal compris dans un document est bien plus facile que dans le code.

Le devis

Le devis s’appuie sur le document de cadrage. Pour chaque lot, il indique ce qui sera fait, combien de temps cela prendra, ce qui est attendu de l’organisation et selon quel critère il sera accepté. Ce qui est hors périmètre est aussi écrit à part. C’est là que l’on précise à qui reviennent le code source et les droits de propriété intellectuelle, et comment se déroulera la maintenance.

La conception

Avant d’écrire du code, nous concevons le modèle de données, la structure des droits et les écrans principaux. Nous montrons les maquettes d’écran aux vrais utilisateurs de l’organisation. Les objections qui apparaissent à ce stade coûtent bien moins cher que celles qui apparaissent plus tard.

Si des données personnelles sont traitées, on décide aussi à ce stade quelles données sont collectées et pourquoi, qui peut les voir et combien de temps elles sont conservées. Ce ne sont pas des fonctionnalités à ajouter plus tard, mais une partie de l’architecture.

Le développement

Nous menons le développement par cycles courts. À la fin de chaque cycle, l’organisation voit une version qui fonctionne dans l’environnement de test. Si quelque chose a été mal compris, on s’en aperçoit en quelques semaines.

Les tests automatisés s’exécutent à chaque modification. Si un test échoue, la version n’avance pas. Nous avons expliqué comment nous le faisons sur notre propre site dans un article à part.

Tests et recette

La recette se fait selon les critères écrits dans le devis. Pour chaque fonctionnalité, des critères concrets du type « dans tel cas, elle donne tel résultat ». L’organisation teste ces critères avec ses propres données, les écarts sont consignés et corrigés.

Quand les critères d’acceptation ne sont pas écrits, le débat « est-ce que ça marche ? » est inévitable. Nous avons expliqué pourquoi dans notre article sur les critères d’acceptation.

La mise en production

La mise en production n’est pas une journée, c’est un petit plan. Si des données doivent être migrées depuis l’ancien système, des migrations d’essai sont faites à l’avance. La façon de revenir en arrière en cas de problème est écrite. Les utilisateurs reçoivent une courte formation et, pendant les premières semaines, les questions obtiennent des réponses rapides.

La maintenance

Après la livraison, les mises à jour de sécurité, les mises à niveau de l’infrastructure et les petites améliorations continuent. Le périmètre de la maintenance et le délai de prise en charge d’un problème sont mis par écrit dès le stade du devis.

Le code source, la documentation et les étapes de déploiement sont remis à l’organisation. Ainsi, si elle veut un jour continuer avec une autre équipe, elle le peut.

Le rôle de l’organisation

À chacune de ces étapes, il faut un interlocuteur côté organisation. Quelqu’un qui connaît le processus métier, qui répond vite aux questions et qui peut tester les versions intermédiaires. Ce qui ralentit les projets, ce n’est le plus souvent pas un problème technique, c’est l’absence de cet interlocuteur.

En bref

Premier rendez-vous, cadrage, devis, conception, développement, recette, mise en production et maintenance. Les étapes s’allongent ou se raccourcissent selon la taille du projet, mais aucune n’est sautée. Écrire à la fin de chaque étape ce qui sera livré évite les surprises à la fin du projet.