--- title: "Un brief de projet logiciel qui donne des devis comparables" description: "Que mettre dans un brief de projet logiciel pour des devis justes : problème, utilisateurs, systèmes, données, budget, ce qui reste ouvert et erreurs à éviter." canonical: https://sdk.enterprises/fr/guides/rediger-un-cahier-des-charges-logiciel language: fr --- # Un brief de projet logiciel qui donne des devis comparables Mis à jour le: 2026-09-26 > Un bon brief de projet logiciel décrit le problème, les utilisateurs, les systèmes concernés et ce à quoi ressemble la réussite, et laisse la solution ouverte aux propositions des partenaires. Envoyez le même brief à chaque partenaire, avec une fourchette de budget et une liste claire de ce qui est figé : les propositions que vous recevrez seront assez précises pour être comparées. ## Un brief sert à rendre les réponses comparables Un brief de projet n'a qu'une mission : permettre à plusieurs partenaires de comprendre votre problème assez bien pour proposer une façon de le résoudre, avec une estimation fiable. Si chaque partenaire comble les trous avec ses propres hypothèses, les propositions diffèrent par leur périmètre plutôt que par leur qualité, et la moins chère est souvent celle qui a fait le moins d'hypothèses. Le brief doit donc être précis sur le problème et modeste sur la solution. Décrivez ce qui doit être vrai une fois le projet terminé, et laissez les partenaires expliquer comment ils y parviendraient. Leurs réponses sur cette partie ouverte sont ce que vous lirez de plus utile. ## Commencez par le problème métier et la façon de juger la réussite Ouvrez sur la raison d'être du projet : ce qui ne fonctionne pas aujourd'hui, qui en souffre et ce que cela vous coûte de ne rien changer. Expliquer que votre équipe des opérations ressaisit dans l'ERP chaque commande reçue par e-mail en dit bien plus à un partenaire que de demander un portail de gestion des commandes. Dites ensuite comment vous jugerez la réussite. Choisissez quelques résultats observables, comme le temps gagné par commande, les erreurs qui n'atteignent plus les clients ou la date à laquelle un ancien système pourra être arrêté. Ces critères deviendront les critères de recette des jalons : formulez-les de façon vérifiable. ## Décrivez les utilisateurs, les systèmes et les données avant les fonctionnalités Le travail d'intégration et de données est facile à sous-estimer quand un partenaire ne le voit pas. Avant de lister des fonctionnalités, décrivez qui utilisera le logiciel, avec quels systèmes il doit fonctionner et quelles données il traite. Les lacunes de cette partie reviennent plus tard sous forme de demandes de modification. - Utilisateurs : qui ils sont, combien environ, où ils travaillent et sur quels appareils. - Systèmes existants : lesquels, qui en est responsable, et s'ils proposent une API documentée ou seulement une base de données et des exports de fichiers. - Données : lesquelles sont personnelles, confidentielles ou réglementées, où elles se trouvent aujourd'hui et quel volume doit être migré. - Exploitation : qui fera tourner le logiciel après la mise en service, et quelles règles d'hébergement ou de cloud votre entreprise applique déjà. - Contraintes : langues, besoins d'accessibilité, normes de sécurité et toute échéance impossible à décaler, avec sa raison. ## Donnez une fourchette de budget et l'échéance qui compte vraiment Beaucoup d'acheteurs taisent leur budget pour voir ce que les partenaires proposent. Résultat : des propositions pour des projets différents, l'un conçu pour le minimum, l'autre pour tout ce que vous avez mentionné. Une fourchette, même large, permet à chaque partenaire de proposer le meilleur projet qui y tient, et de vous dire franchement si ce n'est pas possible. Faites de même pour le calendrier. Indiquez quelle date est ferme et pourquoi, par exemple un contrat qui arrive à échéance ou une obligation réglementaire, et quelles dates ne sont que des préférences. Un partenaire ne peut s'organiser autour d'une date ferme que s'il sait laquelle c'est. ## Indiquez ce qui est figé et laissez le reste ouvert Classez chaque exigence comme figée, souhaitée ou ouverte. Figée signifie qu'une proposition n'est pas recevable sans elle, comme un hébergement dans l'UE ou une connexion via votre fournisseur d'identité existant. Souhaitée signifie que vous avez une raison, mais que vous étudieriez une alternative. Ouverte signifie que vous attendez la recommandation du partenaire. Laissez la technologie ouverte, sauf raison réelle de la figer, comme une équipe interne qui maintiendra le code ou une plateforme sur laquelle votre entreprise s'est standardisée. Quand vous figez un choix, expliquez pourquoi, pour que les partenaires ne consacrent pas leur proposition à le contester. Enfin, demandez à chaque partenaire de répondre selon la même structure : sa compréhension du problème, l'approche, les phases et jalons, les hypothèses, les risques, l'équipe et le modèle commercial. C'est cette structure commune qui rend les propositions comparables en pratique. ## Les erreurs qui rendent les propositions impossibles à comparer Beaucoup de propositions inexploitables répondent à un brief qui les appelait. Supprimez ces travers avant d'envoyer le vôtre. - Une liste de fonctionnalités sans énoncé du problème : chaque partenaire devine vos priorités. - Une longue spécification qui fige la solution avant que quiconque ait examiné le problème. - Aucune mention des systèmes existants ni de la migration des données, qui reviennent ensuite en demandes de modification. - Des précisions données à certains partenaires seulement, lors d'appels : leurs propositions répondent alors à des questions différentes. - Des mots comme simple, standard ou comme une appli bien connue, qui n'ont pas le même sens pour chaque lecteur. - Aucune date limite pour les questions, ou des réponses transmises au seul partenaire qui les a posées. ## Invitez les questions et lisez-les comme un critère d'évaluation Donnez aux partenaires une période définie pour poser leurs questions, répondez par écrit et envoyez chaque réponse à tous. Les questions sont instructives en elles-mêmes : un partenaire qui vous interroge sur vos données, vos utilisateurs et vos critères de recette pense déjà à la livraison. Si le problème reste trop incertain pour être bien décrit, dites-le et demandez une courte phase de cadrage payante plutôt qu'une proposition complète. Un devis ferme bâti sur des suppositions cache les inconnues dans sa marge de risque ; une phase de cadrage remplace les suppositions par des faits. Si vous souhaitez que des ingénieurs relisent votre brief, ou y répondent, vous pouvez l'envoyer via notre formulaire Démarrer un projet. ## À retenir - Décrivez le problème, les utilisateurs et ce à quoi ressemble la réussite, et laissez la solution ouverte. - Le travail d'intégration et de données est facile à sous-estimer : listez chaque système et chaque jeu de données concerné. - Donnez une fourchette de budget et précisez quelle échéance est ferme, et pourquoi. - Classez chaque exigence comme figée, souhaitée ou ouverte, et demandez des propositions selon une structure commune. - Répondez aux questions par écrit et partagez chaque réponse avec tous les partenaires. ## FAQ ### Quelle longueur doit faire un brief de projet logiciel ? Assez pour couvrir le problème, les utilisateurs, les systèmes, les données, les contraintes, la fourchette de budget et le calendrier, ce qui tient en quelques pages pour la plupart des projets. S'il s'allonge beaucoup plus, il décrit probablement la solution plutôt que le problème. ### Faut-il communiquer son budget aux partenaires ? Oui, sous forme de fourchette. Sans elle, les partenaires proposent des projets de tailles très différentes et vous ne pouvez pas les comparer. Une fourchette permet à chacun de montrer ce qu'il ferait dans ce cadre, et de vous dire honnêtement si elle ne suffit pas. ### Faut-il demander un prix forfaitaire en réponse à un brief ? Seulement si le brief décrit le travail avec assez de détails pour l'estimer. Si des questions clés restent ouvertes, demandez une phase de cadrage au forfait ou une fourchette d'estimation avec des hypothèses explicites, puis fixez le prix de la réalisation une fois les inconnues levées. ## Partir de votre besoin - [Création de site internet](https://sdk.enterprises/fr/creation-site-internet) ## Services associés - [Application sur mesure](https://sdk.enterprises/fr/application-sur-mesure) - [Audit technique et conseil](https://sdk.enterprises/fr/audit-technique-logiciel) ## Pour aller plus loin - [Ce qu'une phase de cadrage payante doit vous livrer](https://sdk.enterprises/fr/guides/phase-de-cadrage-logiciel) - [Forfait ou régie : choisir un modèle de contrat logiciel](https://sdk.enterprises/fr/guides/forfait-ou-regie)