Projet logiciel : combien de temps faut-il demander aux équipes métier ?

La première version est prête à être essayée. Nous l'avons montrée aux équipes, transmis un cahier de recette et indiqué ce qu'il fallait tester. La réunion suivante arrive. Les essais n'ont pas été faits : les personnes concernées n'ont pas trouvé le temps.

C'est arrivé sur un projet avec l'ASNR. Nous avons alors fait les tests pendant les ateliers, avec les utilisateurs. Pendant deux à trois semaines, nous les avons accompagnés dans la prise en main, en ajoutant aussi des séances d'une demi-heure pour essayer des parties de l'outil ensemble.

Nous avons eu le sentiment que le problème dépassait la disponibilité dans l'agenda. Entrer dans un nouvel outil semblait représenter un effort important pour ces personnes. Les guider dans les premiers essais a rendu cet effort plus concret et plus accessible.

Combien de temps les équipes métier doivent-elles consacrer à un projet logiciel ? Dans notre pratique, deux à trois heures d'échange par semaine au démarrage donnent un repère utile. Ce rendez-vous représente une partie de la mobilisation. Il faut aussi prévoir la recherche de documents, les échanges internes et, surtout, les essais et l'appropriation.

Deux à trois heures par semaine pour construire un dialogue régulier

Nous choisissons généralement une demi-journée dans la semaine et en réservons une partie pour travailler ensemble. Ce qui compte au début, c'est de se voir régulièrement et de retrouver les mêmes interlocuteurs.

Les personnes responsables de la dimension stratégique côté client participent ponctuellement. Un ou plusieurs représentants de l'équipe métier sont présents de manière régulière. Cette continuité permet d'accumuler la compréhension, de reprendre les décisions précédentes et de construire la confiance.

Nous privilégions aussi des rencontres physiques au démarrage. Par la suite, le rythme peut passer à une réunion tous les quinze jours, avec une alternance entre présence et visio. Il évolue en fonction de ce qu'il reste à comprendre, à décider ou à essayer.

Ces durées décrivent les configurations que nous avons rencontrées. La mobilisation dépend du projet, du nombre de métiers concernés et des sujets à éclaircir. Le rendez-vous hebdomadaire ne constitue pas une estimation de toute la charge côté client.

Choisir un représentant métier capable de porter le changement

La connaissance du métier est indispensable. Elle doit s'accompagner d'une envie de faire avancer le projet. Un logiciel métier change souvent les processus : le représentant doit pouvoir porter ces changements auprès de ses collègues.

Nous cherchons donc une personne qui connaît bien l'activité, les différentes équipes et les interlocuteurs internes. Cette personne se retrouve identifiée comme celle qui porte le projet. Elle peut être amenée à le défendre, à expliquer les choix et à prendre une part de risque lorsqu'une nouvelle manière de travailler est proposée.

Les arbitrages qu'elle doit pouvoir faire concernent notamment les priorités métier. Qu'est-ce qui est essentiel pour les utilisateurs ? Qu'est-ce qui peut attendre ? Ces décisions doivent traduire les besoins de l'équipe qu'elle représente, au-delà de ses seules préférences personnelles.

Sa disponibilité est donc aussi une question de mandat. Il faut préciser les priorités qu'elle peut arbitrer et les décisions qui demandent un échange avec les responsables du projet. Une personne qui connaît très bien le métier mais ne peut jamais trancher devra faire remonter chaque choix : ce temps de décision doit alors être prévu dans l'organisation.

Pour choisir cette personne, trois questions sont utiles : connaît-elle les usages et les personnes concernées ? A-t-elle envie de porter les changements ? Peut-elle représenter l'équipe et décider des priorités, ou obtenir rapidement les arbitrages nécessaires ?

Les premières réunions remplissent progressivement la roadmap

La première réunion sert à poser une trajectoire stratégique. Quelle situation voudrions-nous atteindre dans trois mois ? Dans six mois ? Dans un an ? Les éléments sont encore larges, mais ils donnent un cap.

Dans les échanges suivants, nous proposons des moyens plus concrets d'atteindre ces objectifs. Certaines fonctions paraissent centrales. D'autres demandent d'abord de comprendre une règle ou un processus. Nous remplissons progressivement les cases de cette première roadmap.

Les quinze premiers jours servent souvent à ce travail. Ensuite, nous précisons les propositions et montrons les premières réalisations lorsque le projet entre dans cette phase. Le client peut réagir à quelque chose de visible : est-ce que cette manière de faire lui conviendrait ? Qu'est-ce qui manque ?

Nous déposons les comptes rendus dans un espace partagé, avec les prochaines étapes. Entre les réunions, nous envoyons aussi des nouvelles par Teams, Slack ou email : progression, synthèse, remise en contexte, parfois une capture ou une vidéo d'usage.

Les clients ne répondent pas nécessairement à ces messages. Ils apprécient de voir que le travail continue. Une information d'avancement peut remplir son rôle sans devenir une nouvelle tâche à traiter dans leur journée.

Il faut aussi prévoir du travail entre les réunions

Le représentant métier doit parfois retrouver un document, consulter un collègue ou vérifier une règle. Le projet occupe aussi une place dans sa réflexion, au moment qu'il choisit. Cette contribution ne se mesure pas uniquement à la durée des ateliers.

Nous pouvons alléger une partie de ce travail en préparant les échanges. Les documents reçus en amont sont étudiés. Les propositions arrivent avec des questions précises. Les éléments utiles avant de lancer le projet permettent de commencer cette préparation dès le cadrage.

Pour organiser la disponibilité de l'équipe, il faut donc distinguer le rendez-vous régulier des tâches ponctuelles qui l'entourent. Une recherche documentaire, une décision interne et un essai de fonctionnalité ne demandent pas les mêmes personnes ni le même effort.

Les échanges avec la DSI ont leur propre responsable

Un projet rencontre aussi des contraintes informatiques : accès indisponible à un environnement, technologies autorisées, composants à installer par un autre prestataire. Ces échanges sont pris en charge par un membre de notre équipe projet, qui dialogue avec la direction des systèmes d'information (DSI) et les prestataires concernés.

Nous cherchons à comprendre les contraintes, expliquer les choix et adapter la proposition. Cela peut conduire à préparer un environnement de déploiement particulier, ou à fournir des procédures détaillées en complément des scripts. Les personnes qui installent l'application ont besoin de comprendre les étapes et le contexte.

Sur un projet, une réunion nous a appris que l'espace de stockage existant était utilisé par plusieurs équipes métier et que la DSI avait des attentes techniques différentes de celles que nous avions envisagées. Le stockage partagé devait continuer à vivre pour les autres équipes.

Nous avons décidé de conserver cet espace et de copier les fichiers utiles dans un stockage propre à l'application, adapté à l'environnement autorisé. Une copie initiale a été faite. Un mécanisme de synchronisation ponctuelle a été prévu, après discussion avec le métier, pour pouvoir être déclenché si nécessaire.

Cette réunion a permis de relier les usages et les contraintes techniques dans une même décision. Le métier apportait ce que nous ne pouvions pas deviner sur le partage des fichiers ; notre équipe prenait en charge la recherche d'une solution et sa mise en œuvre.

La recette métier commence par des essais guidés

La recette métier consiste à vérifier que l'outil convient au travail réel des utilisateurs. Lorsque l'outil devient utilisable, nous faisons une démonstration, puis fournissons un cahier de recette guidé. Il indique les éléments à essayer entre deux réunions. Lors des ateliers, nous précisons le module ou la partie de l'application sur lesquels concentrer les prochains tests.

Au début, les utilisateurs ont besoin d'une présentation et d'un accompagnement pour les premiers essais. Lorsqu'ils ont suffisamment pris l'outil en main, ils deviennent plus autonomes. Nous pouvons leur demander d'essayer une partie précise sans reprendre toute l'explication.

Ces modules sont directement issus des discussions avec eux. Ils reconnaissent les sujets qu'ils ont expliqués et voient comment leurs remarques prennent forme. Le passage à l'autonomie se construit au fil de ces essais.

Si les tests prévus entre les réunions n'ont pas eu lieu, comme sur le projet ASNR évoqué au début, nous pouvons utiliser une partie des ateliers pour les faire ensemble. Les séances supplémentaires de trente minutes avaient ici un rôle précis : accompagner l'entrée dans l'outil et débloquer les premiers retours.

Le temps nécessaire pour s'approprier l'outil existe. Notre travail consiste à rendre les premiers pas assez simples pour que les équipes puissent les faire.

Les tests automatiques et les essais métier répondent à deux questions

Il est difficile de suivre exactement tous les essais réalisés par les utilisateurs. De notre côté, nous mettons en place des tests automatiques, y compris des tests dans le navigateur, pour limiter les régressions techniques. Sur les parcours couverts par ces tests, nous pouvons détecter certains défauts même si les utilisateurs n'ont pas refait les essais correspondants.

Ces tests ne peuvent pas déterminer si un écran correspond bien au contexte de travail d'une personne. Les utilisateurs apportent une autre lecture : une information serait plus utile ailleurs, une opération devrait être plus directe, un enchaînement pourrait être plus pratique.

Quand ils voient que l'essentiel fonctionne et que leurs retours peuvent améliorer leur futur quotidien, les essais prennent une autre place. Ils participent à la construction de l'outil. Il nous est arrivé que des personnes déplacent d'autres réunions pour pouvoir tester et échanger avec nous.

Cette disponibilité se gagne progressivement. Elle repose sur les propositions montrées, les corrections apportées et la confiance construite depuis la conception. C'est une des raisons pour lesquelles le premier lot de cadrage a aussi une dimension relationnelle.

Organiser la participation du métier aux moments clés

Au démarrage, réservez des échanges réguliers avec des représentants métier qui pourront revenir. Identifiez aussi les personnes capables d'arbitrer les objectifs et les contraintes. Entre les réunions, rendez explicites les documents à rechercher et les questions à éclaircir.

À l'arrivée des premières versions, prévoyez la démonstration et les essais guidés. Le temps nécessaire évoluera avec la prise en main. Certaines équipes pourront tester seules rapidement ; d'autres auront besoin de séances accompagnées.

Nous pouvons porter la formalisation, préparer les propositions et prendre en charge les sujets techniques. La participation du métier reste nécessaire pour expliquer l'activité, décider et s'approprier l'outil. Nous détaillons cette répartition dans notre article sur la conduite d'un projet numérique avec des équipes débordées.

Si la disponibilité de vos équipes vous empêche de lancer un projet, regardons ensemble les moments où leur participation sera nécessaire. Cela permet de discuter un rythme qui tient dans leur activité.