Lot de cadrage d’un logiciel sur mesure : qu’a-t-on à la fin ?
Des documents, des maquettes et une feuille de route : le cadrage doit rendre la suite du projet plus concrète. Sur un projet ASNR parti d’un gros tableau Excel, le premier engagement a aussi amorcé la réalisation. Voici ce que le client en a retiré.
Terrain
L'équipe savait qu'elle voulait des graphes dans son futur outil. Elle n'était pas vraiment convaincue que ce serait possible. Une petite démonstration d'interface, préparée à part, a permis de rendre cette possibilité visible. Des échanges autour d'un café, avec nos responsables techniques ou fonctionnels, ont prolongé la discussion sur ce que nous pourrions construire.
La fonctionnalité a rejoint le périmètre. Et la relation de travail a changé. Le client nous faisait déjà confiance dans un cadre institutionnel ; les personnes métier, elles, découvraient notre équipe. C'est en voyant que nous pouvions comprendre leur intention et la traduire qu'elles ont commencé à nous faire confiance à leur tour.
Cette scène appartient à un projet avec l'ASNR, parti d'un gros tableau Excel et d'un besoin encore à préciser. Elle dit quelque chose de ce que nous cherchons dans un lot de cadrage de logiciel sur mesure : rendre la compréhension visible, éclaircir les possibilités et donner au client une base pour organiser la suite.
Que doit produire un lot de cadrage logiciel ?
Nous appelons généralement lot 0 la phase de conception. Il s'agit de comprendre le besoin, de poser des limites, de distinguer ce qui paraît réaliste de ce qui demande une autre approche. Le travail produit des restitutions que le client peut examiner et discuter.
Sur le projet ASNR, le premier engagement était vendu comme un temps de conception, avec des livrables documentaires. Il a duré environ deux mois, dont un mois et demi consacré à la conception. Vers la fin de cette phase, nous avons anticipé la réalisation et commencé à construire le socle technique. Ce premier engagement a ainsi réuni les lots 0 et 1.
Ce socle comprend notamment la base de données et les premiers composants sur lesquels l'application sera construite. Il marque le début de la réalisation, même si le dialogue de conception se poursuit encore.
À la fin de ces deux mois, le client disposait donc des livrables de conception et d'un premier socle. Le socle technique relève de la réalisation : pour votre projet, il faut préciser si le premier engagement couvre uniquement la conception ou comprend aussi ce début de construction.
La roadmap, autrement dit la feuille de route, remise à la fin restait générale : les phases, les points chauds anticipés et les grandes périodes de test donnaient une idée de la suite. Elle ne précisait pas encore chaque fonctionnalité.
Des maquettes pour discuter les usages
Comprendre le besoin commence par le dialogue et la restitution. Nous expliquons ce que nous avons compris, nous le représentons et nous le soumettons au client. Les documents et les maquettes permettent de repérer ce qui correspond à son activité, ce qui manque et ce que nous avons interprété de travers.
À la fin de la conception, nous avions notamment des maquettes qui traduisaient les échanges visuellement et proposaient une identité graphique. Des premiers parcours d'usage et des explications complétaient l'ensemble.
Une petite démonstration sans base de données ni enregistrement rendait aussi l'interface plus tangible. Elle servait à alimenter le dialogue. Elle ne permettait pas encore aux utilisateurs d'enregistrer et de retrouver leur travail comme dans l'application finale.
Les maquettes ont particulièrement intéressé les personnes métier. Elles pouvaient voir leur futur outil prendre forme. La démonstration montrait aussi que nous étions capables de construire une interface proche de ces propositions.
Des échanges préliminaires avec la DSI
La conception comprend des premiers contacts avec la direction des systèmes d'information (DSI) du client. Nous cherchons à comprendre ce qui est acceptable et les contraintes qui pourraient modifier la réalisation. Les comptes rendus et les échanges internes avec la DSI donnent au client une autre lecture du cadrage.
Sur ce projet, la DSI nous a recommandé certaines technologies et exprimé des réserves sur d'autres. Nous avons adapté la proposition à ses attentes. Quand le socle technique a été construit, elle a pu constater que nous savions utiliser cet environnement et dialoguer avec ses équipes.
Les documents et les procédures adaptés à cet environnement comptaient aussi. Ils montraient que nous avions pris le temps de le comprendre. Le socle technique a donc rassuré la DSI sur une dimension que les maquettes seules ne pouvaient pas éclairer.
L'équipe métier et la DSI n'avaient pas exactement besoin des mêmes preuves. L'équipe métier s'intéressait aux usages représentés. La DSI regardait les choix, les contraintes et la capacité à préparer une réalisation compatible avec son environnement.
Une roadmap qui indique les phases et les points chauds
Le cadrage sert aussi à organiser le travail dans le temps. La première roadmap reste large. Elle relie les objectifs aux phases à venir, signale les difficultés anticipées et réserve les grandes périodes d'essai.
Elle permet au client de comprendre comment nous envisageons la progression et où ses équipes seront sollicitées. C'est le lien avec le temps à prévoir côté métier : les échanges de conception et l'appropriation de l'outil demandent une disponibilité qui doit trouver sa place dans le projet.
La roadmap n'est pas un cahier des charges exhaustif sous une autre forme. Elle pose une trajectoire, que nous préciserons avec les échanges et les premières réalisations. Elle peut donner suffisamment de visibilité pour décider d'un prochain lot tout en conservant des détails à examiner.
À quoi ressemble une feuille de route d'ensemble ?
Nous la présentons souvent mois par mois, avec les lots, leurs grands objectifs, les fonctionnalités clés et les livrables attendus. Les alertes y ont leur place : un stockage à clarifier avec la DSI, ou des utilisateurs à migrer à une date donnée.
Le tableau suivant est un exemple illustratif de cette structure. Les mois et les lots servent à montrer comment lire la feuille de route ; ils ne reproduisent pas le calendrier du projet ASNR évoqué ici. La durée des lots reste à définir selon le projet.
| Période et lot | Objectifs et livrables attendus | Points de vigilance |
|---|---|---|
| Décembre, lot 0 | Conception, premières maquettes et feuille de route. Préparer la transition prévue en février. | Clarifier le stockage des données avec la DSI et identifier les utilisateurs concernés par la migration. |
| Janvier, lot 1 | Premières réalisations et préparation des parcours de transition. | Organiser les essais avec les représentants métier avant la migration. |
| Février, lot 2 | Migration des utilisateurs vers la nouvelle plateforme et accompagnement de la prise en main. | Prévoir la disponibilité des personnes qui vont essayer l'outil et accompagner la transition. |
| Mars, lot 3 | Ajustements et fonctionnalités suivantes, selon les priorités retenues. | Prendre en compte les retours d'usage pour préciser le contenu du lot. |
Le point chaud « migration en février » a une conséquence dès décembre : il faut commencer à la préparer. La roadmap rend cette dépendance visible assez tôt pour organiser les échanges et les essais. Sans cette anticipation, les préparatifs risqueraient d'arriver au moment même où les utilisateurs doivent changer d'outil.
Un autre document détaille ensuite ce que signifie chaque grand objectif. « Migrer les utilisateurs » doit progressivement devenir une description des personnes concernées, des parcours attendus et des essais à réaliser. Ce document se remplit au fil du dialogue : la roadmap donne la vue d'ensemble, les précisions fonctionnelles permettent de construire et de vérifier chaque partie.
| Ce que le client avait reçu | Ce que cela rendait visible |
|---|---|
| Les documents et comptes rendus de conception | La compréhension du besoin, les échanges et les contraintes identifiées. |
| Les maquettes et les premiers parcours | La traduction des usages et une proposition d'identité graphique. |
| Une démonstration d'interface | Une première représentation concrète des possibilités, sans enregistrement des données. |
| Une roadmap macro | Les phases, les points chauds anticipés et les grandes périodes de test. |
| Le socle technique, dans cet engagement réunissant les lots 0 et 1 | Une première construction adaptée à l'environnement attendu par la DSI. |
Le cadrage peut aussi ouvrir une possibilité
Poser des limites fait partie de la conception. Elle peut aussi conduire à réexaminer une ambition que le client avait mise de côté.
Pour les graphes, l'intention existait déjà. Ce qui manquait, c'était la conviction que nous pouvions en faire quelque chose. La démonstration d'interface et les échanges sur nos expériences ont permis d'en discuter concrètement. La fonctionnalité a trouvé sa place dans le périmètre.
Nous n'avons donc pas seulement recueilli une demande. Nous avons apporté des possibilités à la discussion. Le client a vu que notre équipe pouvait absorber son contexte et le faire réfléchir sur la manière de construire l'outil.
Le client peut déjà faire confiance à Improba. La confiance des personnes qui vont travailler avec nous se construit dans les échanges et les premières propositions.
Les mêmes personnes, avec un intérêt pour le métier
Pour construire cette compréhension, la continuité des interlocuteurs compte beaucoup. Il faut se retrouver, reprendre les échanges précédents et approfondir ce qui n'a pas encore été compris.
Nous cherchons aussi des affinités entre les personnes. Face à une équipe scientifique, des ingénieurs ou des docteurs en sciences peuvent partager des repères utiles. Dans d'autres contextes, ce seront d'autres sensibilités et d'autres expériences qui faciliteront le dialogue.
L'essentiel est que les personnes mises en face du métier aient un intérêt pour ce qu'il fait. Les parcours n'ont pas besoin d'être identiques. Cette curiosité permet de poser les bonnes questions, de se documenter et de revenir avec des propositions qui tiennent compte de l'activité.
Elle fait partie du travail de conception. Une compréhension formalisée dans un document est plus solide quand elle a été construite dans plusieurs échanges et corrigée avec les personnes concernées.
Décider de la suite à partir d'un travail déjà visible
Dans ce projet, le client nous faisait déjà confiance. Le cadrage a surtout renforcé la relation avec l'équipe métier et rassuré la DSI. Sur d'autres projets, notamment avec un nouveau client, nous organisons un premier lot qui lui permet de choisir ensuite s'il poursuit.
Ce qu'il examine à ce moment-là est concret : la qualité de notre compréhension, les propositions, les contraintes identifiées et la trajectoire envisagée. Il peut juger le travail effectué et discuter le prochain engagement.
S'il s'arrête, les restitutions restent une base pour continuer la réflexion. Sur le projet ASNR, le corpus documentaire, les maquettes, la démonstration et le socle auraient fourni de la matière pour reprendre le travail, y compris avec une autre équipe. Cela ne transmet pas automatiquement tout ce qui a été compris dans les conversations, mais le travail de conception laisse des éléments utilisables.
Si vous préparez un projet, vous pouvez donc demander ce que couvre exactement ce premier engagement : compréhension et conception, ou aussi début de réalisation ? Quels livrables recevrez-vous ? Quelle visibilité aurez-vous sur la suite ? Le périmètre du premier lot, son budget et les modalités de décision sur les lots suivants doivent être discutés au départ.
Vous pouvez arriver avec un ancien outil, des documents ou un prototype. Le premier lot sert à transformer cette matière en une compréhension partagée et en propositions à discuter. Il donne une forme concrète à l'approche que nous décrivons dans notre article sur les projets numériques avec des équipes métier débordées.
Vous voulez savoir ce qu'un premier lot devrait éclaircir dans votre situation ? Parlons de son périmètre et de ses livrables.