Cadrage fonctionnel d'un projet remporté sur appel d'offres

Secteur : public - Service : Cadrage fonctionnel

Le projet avait été remporté sur appel d'offres. Il fallait maintenant transformer le dossier en quelque chose qu'une équipe technique puisse réellement construire.

Le contexte

Un partenaire avait remporté un appel d'offres nécessitant une phase de cadrage rigoureuse avant que ses équipes techniques ne puissent démarrer le développement. Le projet impliquait plusieurs interlocuteurs côté client, avec des attentes qui n'avaient pas encore été formalisées de façon homogène.

L'intervention

Mon rôle s'est limité volontairement au cadrage : recueil du besoin auprès des différents interlocuteurs du client, identification des points d'ambiguïté ou de divergence entre ce qui avait été compris par chacun, puis rédaction des spécifications fonctionnelles.

Une fois le document rédigé, il a été validé avec le client avant transmission aux équipes techniques de mon partenaire, qui ont ensuite pris le relais pour la suite : spécifications techniques, développement, livraison.

Je ne suis pas intervenu sur la partie technique du projet, ni sur son suivi une fois le développement lancé. La mission s'arrêtait précisément là où le cadrage se terminait.

Pourquoi confier le cadrage à quelqu'un d'externe et dédié

Une équipe technique qui doit à la fois cadrer et développer a naturellement tendance à commencer à penser en solution avant d'avoir complètement clarifié le besoin.

Ce n'est pas un problème de compétence. C'est un biais difficile à éviter : quand on sait déjà comment on va construire quelque chose, on finit facilement par interpréter le besoin à travers cette solution.

Dans ce projet, j'intervenais justement en dehors de cette logique. Mon rôle n'était pas de préparer mon propre développement, puisque je n'allais pas développer la solution. Mon rôle était de faire préciser le besoin jusqu'à ce qu'une autre équipe puisse le construire sans avoir à deviner ce que le client avait voulu dire.

Les aspects techniques

Cette mission ne comprenait ni développement, ni choix d'architecture, ni pilotage de la réalisation.

C'est volontaire : le cadrage devait produire un livrable exploitable par une autre équipe, sans dépendre de la personne qui l'avait rédigé.

L'enjeu était donc ailleurs : transformer des échanges parfois ambigus en spécifications suffisamment précises pour qu'une équipe technique puisse ensuite faire ses propres choix d'implémentation.

Le résultat

À l'issue du cadrage, les équipes techniques disposaient d'un document validé par le client et suffisamment précis pour commencer leur travail sans devoir réinterpréter le besoin à chaque étape.

Le projet pouvait donc passer du « voilà ce que nous pensons avoir compris » au « voilà précisément ce qui doit être construit ».

Et surtout, le document ne dépendait pas de moi pour la suite : les équipes techniques de mon partenaire pouvaient s'en servir directement pour produire leurs spécifications techniques et développer la solution.

Ce que ce projet illustre

Le cadrage n'est pas toujours une étape que l'on confie par défaut à l'équipe qui va développer. Séparer les deux rôles, celui qui clarifie le besoin et celui qui construit la solution, peut réduire le risque de malentendu, notamment sur des projets où plusieurs interlocuteurs côté client n'ont pas nécessairement la même vision du besoin.

Cette façon de travailler a d'ailleurs créé une relation suffisamment utile pour que mon partenaire continue à me solliciter ponctuellement sur des missions de cadrage similaires.

Questions fréquentes