Périmètre de projet : que définir avant d’embaucher un dev

Avant de confier votre logiciel à quelqu’un pour qu’il le construise, un document décide si vous allez recevoir ce que vous avez payé. Comment écrire un périmètre de projet qui protège le budget d’un fondateur non technique.

Camille avait trois bullets dans un audio WhatsApp. “Une app de prise de rendez-vous pour la clinique, avec paiement et rappel par message.” Le freelance a écouté, a renvoyé un devis de 28 000 euros et un délai de huit semaines. Elle a validé. Quatre mois plus tard le chiffre était à 51 000 euros, l’app n’était toujours pas en ligne, et les deux se disputaient par message pour savoir si “rapport de facturation” avait ou non fait partie de l’accord initial.

Personne n’a menti. Personne n’a été incompétent. Le problème, c’est que le périmètre du projet vivait dans la tête de Camille, et personne ne l’en a jamais sorti pour le mettre sur le papier. Chaque fois qu’elle demandait “juste un petit truc en plus”, le freelance disait oui, parce qu’aucune ligne écrite ne disait où le travail s’arrêtait. Le périmètre n’a pas été violé. Il n’a jamais existé.

Pour un fondateur qui ne code pas, le périmètre de projet est le document le moins cher et le plus sous-estimé de la construction d’un logiciel. Un périmètre de projet, c’est le document qui définit, par écrit, ce qui est livré, ce qui reste dehors et ce qui compte comme terminé, avant qu’une seule ligne de code n’existe. Pour un fondateur non technique, c’est le document le moins cher et le plus sous-estimé du build. C’est le contrat entre le problème qui est dans votre tête et le code que quelqu’un d’autre écrit. Quand il est bon, le budget tient et la conversation avec celui qui construit reste civilisée. Quand il est vague, chaque “imprévu” devient une négociation, et vous perdez presque toujours.

Qu’est-ce que le périmètre d’un projet

Le périmètre d’un projet est le document qui définit les limites du travail : ce qui sera livré, ce qui ne le sera pas, et quels résultats comptent comme “terminés”. Il répond à trois questions avant que le moindre code n’existe : quel problème le logiciel résout, ce qui est dans l’accord, et ce qui reste dehors. C’est la frontière du projet, tracée par écrit.

Remarquez le mot “frontière”. Un périmètre n’est pas une liste de souhaits ni une description enthousiaste du produit de vos rêves. C’est une clôture. Il dit “ceci oui, cela non”, et le “cela non” compte autant que le “ceci oui”. La plus grande partie de l’argent qui disparaît dans les projets logiciels disparaît dans la zone grise entre ce que le fondateur a imaginé et ce que le développeur a compris. Le périmètre existe pour effacer ce gris.

Les guides de gestion de projet ont tendance à traiter le périmètre comme une formalité de planning, quelque chose qu’un chef de projet certifié remplit dans un template. Pour le fondateur non technique, c’est autre chose : c’est la traduction de votre intention dans un langage qui survit à un désaccord. Si vous et celui qui construit vous heurtez dans trois mois, et à un moment vous allez être en désaccord sur quelque chose, le périmètre est le seul document qui tranche la discussion sans rancune.

Périmètre du produit et périmètre du projet : la différence qui économise de l’argent

Il vaut la peine de séparer deux termes qui vivent collés et embrouillent tout le monde. Le périmètre du produit décrit le “quoi” : les fonctionnalités, les écrans, ce que l’utilisateur final peut faire. Prendre un rendez-vous, payer par carte, recevoir un rappel. Le périmètre du projet décrit le “comment” et le “jusqu’où” : le travail nécessaire pour livrer ce produit, y compris ce qui est dans le contrat et ce qui n’y est pas.

En pratique un fondateur a besoin des deux, mais se trompe plus souvent sur le second. Presque n’importe qui peut lister ce que l’app doit faire. Presque personne n’écrit ce que le projet n’inclut pas. Et c’est exactement là que le budget explose : pas sur les fonctionnalités que vous avez listées, mais sur celles que vous avez supposées évidentes et que le développeur a supposées dehors.

Un exemple concret. “L’app envoie un rappel par message” est du périmètre de produit. Maintenant viennent les questions de périmètre de projet : le rappel part par SMS, par WhatsApp, ou par e-mail ? Qui paie la facture de l’API de messagerie ? Si la clinique veut changer le texte du rappel elle-même, c’est un panneau de configuration, et est-ce dans l’accord ? Chacune de ces réponses coûte des heures de travail. Un périmètre qui s’arrête à “envoie un rappel” a laissé trois décisions d’argent ouvertes, et sur toutes le silence se lit en faveur de celui qui facture à l’heure.

Pourquoi le périmètre est l’assurance la moins chère qu’un fondateur puisse acheter

Pensez au périmètre comme à une assurance. Vous passez quelques heures à écrire un document qui, dans le meilleur des cas, paraît inutile parce que rien n’a mal tourné. Mais le coût de ne pas l’avoir apparaît toujours au pire moment : quand l’argent est déjà dépensé, le délai déjà explosé, et qu’il ne reste, pour régler le différend, que la mémoire sélective de deux personnes fatiguées.

Les fondateurs non techniques sont particulièrement exposés ici pour une raison simple : vous ne pouvez pas juger le travail par le code. Vous n’ouvrez pas le dépôt pour vérifier que tout est là. Votre seule ancre de “ceci a été livré comme convenu” est le document qui décrit le convenu. S’il n’existe pas, vous faites entièrement confiance à la bonne foi et à la bonne mémoire de l’autre côté, et les deux s’usent vite sous la pression du délai.

Il y a un nom pour ce qui arrive quand le périmètre est lâche : le scope creep, la croissance silencieuse du travail sans que personne ne renégocie le prix. Le périmètre de projet est l’antidote. Pas parce qu’il empêche les changements, puisque tout projet change, mais parce qu’il transforme chaque changement en une décision consciente, avec prix et délai sur la table, au lieu d’un “tant qu’on y est” que personne n’a facturé.

Et le coût d’en écrire un ? Presque rien. Quelques heures des vôtres, peut-être une conversation structurée avec celui qui va construire. Comparé à 23 000 euros de dépassement comme celui de Camille, c’est le meilleur retour par heure qu’un fondateur obtient dans la phase de build.

Ce qui entre vraiment dans un périmètre de logiciel

Les guides génériques vous diront qu’un périmètre a “sept éléments” et listeront des choses comme justification, jalons et organigramme des tâches. C’est du vocabulaire de chef de projet certifié, et pour une clinique qui embauche pour une app, c’est du poids mort. Le périmètre d’un logiciel, écrit par un fondateur pour celui qui construit, a besoin de six choses, et aucune n’est un joli diagramme.

La première, c’est le problème. Une ou deux phrases sur ce qui est cassé aujourd’hui et quel résultat business vous attendez. “Aujourd’hui l’accueil prend les rendez-vous sur un carnet et perd 15 % des consultations faute de confirmation ; je veux réduire de moitié le taux de lapins.” Cela ancre toutes les décisions suivantes.

La deuxième, ce sont les utilisateurs. Qui touche au système ? Réceptionniste, patient, propriétaire de la clinique ? Chaque type d’utilisateur est un ensemble d’écrans et de permissions. En oublier un est la façon la plus courante de découvrir un tiers de travail en plus à mi-chemin.

La troisième, c’est ce qui est dedans : la liste des fonctionnalités, décrites avec des verbes concrets. “Le patient prend, déplace et annule un rendez-vous.” “Le système débite la carte au moment de la prise de rendez-vous.” Fuyez les verbes vagues comme “gérer”, “optimiser” ou “intégrer”. Ils paraissent précis et ne le sont pas ; chacun cache une semaine de travail non convenu.

La quatrième, c’est ce qui est dehors, et elle mérite sa propre section, parce que c’est la partie que presque tout périmètre oublie et que presque tout budget regrette.

La cinquième, ce sont les critères de terminé. Comment saurez-vous qu’une fonctionnalité est livrée ? “Prise de rendez-vous terminée” est discutable. “Un patient peut prendre rendez-vous depuis son téléphone, reçoit une confirmation, et le rendez-vous apparaît sur l’agenda de l’accueil en temps réel” est vérifiable. Sans cela, “terminé” devient une opinion, et vous allez perdre le débat d’opinion contre la personne qui a écrit le code.

La sixième, ce sont les hypothèses et dépendances. Allez-vous fournir les textes et le logo ? La clinique a-t-elle déjà un compte sur la passerelle de paiement, ou cela entre-t-il dans le projet ? L’app dépend-elle d’un système qui existe déjà ? Une hypothèse non écrite est un risque transféré sur vous sans que vous le sachiez.

Si vous voulez approfondir chaque fonctionnalité une fois le périmètre fermé, le document suivant est le document d’exigences, qui détaille le comportement de chaque écran. Le périmètre est la frontière ; les exigences sont la carte de ce qui vit à l’intérieur.

La liste du “hors périmètre” est votre arme secrète

Si vous ne parvenez à écrire qu’une seule section du périmètre, écrivez celle-ci. La liste du hors périmètre, ce que le projet n’inclut explicitement pas, est l’élément le plus puissant et le plus ignoré de tout le document.

La raison est psychologique. Quand vous listez ce qui est dedans, vous créez une attente. Mais la tête d’un fondateur fonctionne par association : vous avez demandé la prise de rendez-vous, donc “évidemment” le système a un rapport du nombre de consultations effectuées, non ? Pour vous, c’est évident. Pour celui qui n’a chiffré que la prise de rendez-vous, c’est du travail nouveau. La liste du hors périmètre tue cette ambiguïté avant qu’elle ne devienne une facture.

Écrire “hors périmètre” change aussi la conversation côté builder. Au lieu que le développeur dise non à chaque demande, ce qui crée des frictions et vous fait culpabiliser de demander, le document a déjà dit non par écrit, de façon neutre, au début, quand personne n’était investi émotionnellement. “Rapports financiers, intégration avec le système comptable et app iOS sont hors de ce périmètre et peuvent être chiffrés dans une phase ultérieure.” Maintenant, quand vous demandez le rapport, vous savez tous les deux que c’est une nouvelle phase avec son propre prix, et non une trahison de l’accord.

Les fondateurs expérimentés traitent la liste du hors périmètre comme l’endroit où ils rangent les bonnes idées pour plus tard. Vous ne dites pas jamais. Vous dites pas maintenant, et vous numérotez la file. Cela protège le budget de cette phase sans tuer l’ambition du produit.

Comment écrire un périmètre de projet : un exemple réel

Montons-en un, court, avec le cas de la clinique. Pas besoin de logiciel coûteux ni de template de cabinet de conseil. Un document d’une à deux pages suffit.

Problème : l’accueil prend les rendez-vous sur un carnet et par téléphone ; 15 % des consultations deviennent des lapins faute de confirmation. Objectif : faire passer le taux de lapins sous 8 % en trois mois.

Utilisateurs : patient (prend et confirme), réceptionniste (voit l’agenda du jour, déplace), propriétaire de la clinique (voit la facturation du mois).

Dans le périmètre : le patient prend, déplace et annule depuis son téléphone ; le système débite l’acompte sur la carte à la prise de rendez-vous ; le système envoie un rappel WhatsApp 24h avant ; l’accueil voit l’agenda du jour en temps réel ; le propriétaire voit le total facturé sur le mois.

Hors périmètre (phase 2 ou jamais) : dossier médical électronique ; intégration avec le système comptable ; app native iOS et Android (la v1 est web sur le téléphone) ; rapports au-delà de la facturation mensuelle ; gestion des mutuelles.

Critères de terminé : un vrai patient peut prendre rendez-vous, payer l’acompte et recevoir la confirmation WhatsApp sans aide ; le rendez-vous apparaît sur l’agenda de l’accueil en cinq secondes maximum ; le rappel se déclenche tout seul 24h avant.

Hypothèses : la clinique fournit logo, textes et le compte de la passerelle de paiement ; le contenu médical n’est pas validé par le développeur ; l’hébergement est à la charge de celui qui construit pendant les trois premiers mois.

Voilà un périmètre. Il tient sur une page, n’importe qui le lit en trois minutes, et il élimine déjà les trois disputes les plus chères du projet de Camille : le rapport qu’elle croyait inclus, l’app native qu’elle a supposée, et qui payait la facture WhatsApp. Avant de confier cela à une software house ou à un freelance, il vaut la peine de faire un recueil des besoins honnête, en parlant à ceux qui vont utiliser le système tous les jours. Un périmètre tient bien mieux quand il naît de ce que les gens font réellement, et non de ce que vous imaginez qu’ils font.

Les quatre erreurs qui font exploser le budget

Après avoir lu des dizaines de périmètres qui ont mal tourné, les mêmes quatre erreurs reviennent.

La première, c’est le verbe vague. “Le système gère les patients” peut signifier un simple fichier ou un CRM complet avec historique, segmentation et automatisation. La différence entre les deux est un mois de travail. Chaque fois qu’un élément du périmètre utilise gérer, intégrer, optimiser ou traiter, arrêtez-vous et décrivez l’action concrète.

La deuxième, c’est l’absence de la liste du dehors. On en a parlé, mais cela vaut la peine de le répéter, parce que c’est l’erreur qui coûte le plus. Un périmètre sans frontière de sortie n’est pas un périmètre. C’est une lettre de bonnes intentions que le temps va étirer.

La troisième, c’est confondre périmètre et délai. “Je le veux prêt en deux mois” n’est pas un périmètre, c’est un souhait. Le délai sort du périmètre, pas l’inverse. Quand vous fixez la date avant de définir le travail, l’une de deux choses cède : soit le périmètre rétrécit sans que vous le remarquiez, soit la qualité s’effondre pour tenir dans la date.

La quatrième, c’est traiter le périmètre comme immuable. L’erreur inverse, et tout aussi chère. Un bon périmètre ne fige pas le projet ; il crée un processus pour le changer. La règle est simple : le changement est permis, à condition d’entrer comme une décision explicite, avec un impact de prix et de délai convenu avant de devenir du code. Le périmètre n’empêche pas le changement. Il empêche le changement gratuit et silencieux.

Périmètre, exigences et contrat ne sont pas la même chose

Trois documents différents que les fondateurs amalgament souvent en un seul, et qu’il vaut la peine de séparer.

Le périmètre est la frontière : ce qui entre, ce qui sort, ce qui compte comme terminé. Il est court, stratégique, lu en minutes.

Les exigences sont le détail de chaque élément à l’intérieur de la frontière : comment chaque écran se comporte, ce qui se passe quand la carte est refusée, quels champs sont obligatoires. C’est long, technique au sens de détaillé, et presque toujours écrit après le périmètre.

Le contrat est le document juridique qui verrouille prix, délai, propriété du code et ce qui se passe si quelque chose tourne mal. Le périmètre devient souvent une annexe du contrat, justement pour que “le convenu” ait une valeur formelle. Il vaut la peine de lire celui qui a défendu, il y a plus de vingt ans, qu’écrire la spécification fonctionnelle avant de construire coûte moins cher que de la découvrir en construisant. L’argument a bien vieilli.

L’ordre compte. Périmètre d’abord, exigences ensuite, contrat liant les deux. Sauter le périmètre et aller droit au contrat, c’est signer un chiffre sans savoir exactement ce qu’il achète. C’est comme conclure la rénovation d’une maison au prix du mètre carré sans dire combien de pièces.

Questions fréquentes

Qu’est-ce que le périmètre d’un projet ?

C’est le document qui définit les limites du travail : ce qui sera livré, ce qui reste dehors, et quels résultats comptent comme achevés. Pour un projet logiciel, il traduit l’intention du fondateur en une frontière écrite, avant que le moindre code n’existe, pour que les deux parties sachent exactement ce qui fait et ne fait pas partie de l’accord.

Comment écrire un périmètre de projet, avec un exemple ?

Écrivez une à deux pages avec six blocs : le problème et l’objectif business ; les utilisateurs ; ce qui est dedans (en verbes concrets) ; ce qui est dehors ; les critères de terminé ; et les hypothèses et dépendances. Dans l’exemple de la clinique de prise de rendez-vous, “dedans” inclut prendre rendez-vous, débiter l’acompte et envoyer un rappel ; “dehors” inclut le dossier médical et une app native ; “terminé” signifie un vrai patient qui prend rendez-vous et paie sans aide. Cela tient sur une page et élimine les disputes les plus chères avant qu’elles n’arrivent.

Quelle est la différence entre périmètre du produit et périmètre du projet ?

Le périmètre du produit décrit le “quoi” : les fonctionnalités et ce que l’utilisateur peut faire. Le périmètre du projet décrit le “comment” et le “jusqu’où” : le travail nécessaire pour livrer ce produit, y compris ce qui est dans et hors du contrat. Les fondateurs se trompent plus souvent sur le second, parce qu’il est facile de lister des fonctionnalités et difficile d’écrire ce que le projet n’inclut pas.

Quels sont les éléments d’un périmètre de projet logiciel ?

Les guides génériques citent sept éléments de gestion de projet, mais pour un logiciel commandé par un fondateur, six suffisent : le problème, les utilisateurs, ce qui est dedans, ce qui est dehors, les critères de terminé, et les hypothèses et dépendances. La liste du “hors périmètre” est la plus importante et la plus oubliée ; c’est elle qui empêche les idées associées de devenir du travail non facturé.

Le périmètre, est-ce la même chose que les exigences ?

Non. Le périmètre est la frontière du projet, court et stratégique. Les exigences sont le détail de chaque élément à l’intérieur de cette frontière, long et précis, écrit après le périmètre. Le périmètre dit qu’il existe un écran de prise de rendez-vous ; les exigences décrivent comment il se comporte quand le paiement échoue. Les deux sont nécessaires, mais ils servent des objectifs différents et tiennent presque jamais dans le même document.