Un brief clair est la clé pour obtenir une estimation juste d'un prestataire de développement informatique. Questions à se poser, contenu du brief, critères de choix, contrat et erreurs à éviter.
Pour bien présenter votre projet à un prestataire de développement informatique, préparez un brief court mais précis : le problème à résoudre, les utilisateurs visés, les fonctionnalités indispensables classées par priorité, les outils avec lesquels le logiciel doit communiquer, votre budget et votre calendrier. Choisissez ensuite le prestataire sur des critères vérifiables (références proches de votre projet, méthode de travail, maintenance, propriété du code) plutôt que sur le seul prix.
On reprend ici les questions à vous poser avant le premier contact, le contenu d’un bon brief, les critères pour choisir une société de développement, les points à verrouiller dans le contrat et les erreurs qui font dérailler un projet dès le départ.
- Que fait un prestataire de développement informatique ?
- Quelles questions vous poser avant de le contacter ?
- Que mettre dans le brief de votre projet ?
- Comment choisir le bon prestataire ?
- Comment se passe le premier contact ?
- Quels points vérifier dans le contrat ?
- Quelles erreurs éviter ?
- Questions fréquentes
- Sources
Que fait un prestataire de développement informatique ?
Un prestataire de développement informatique conçoit et réalise un logiciel pour votre compte : application web, application mobile, outil métier interne, extranet client, connecteur entre deux logiciels. Selon sa taille, il peut s’agir d’un développeur indépendant, d’une agence web, d’une entreprise de services du numérique (ESN) ou d’un éditeur qui adapte son propre produit.
Le point commun de tous ces profils : ils ne connaissent pas votre métier aussi bien que vous. Leur travail consiste à traduire un besoin d’entreprise en choix techniques, en écrans et en code. Plus votre besoin est exprimé clairement, plus l’estimation sera juste et moins il y aura de mauvaises surprises en cours de route. C’est tout l’enjeu de la présentation du projet.
Quelles questions vous poser avant de le contacter ?
Avant d’écrire à qui que ce soit, prenez une heure pour clarifier votre besoin. Un projet informatique demande à la fois une bonne compréhension de vos clients (ou de vos équipes) et des technologies capables de résoudre leur problème. Vous apportez la première partie, le prestataire la seconde. Répondez par écrit à ces questions :
- Quel problème précis voulez-vous résoudre ? Une tâche manuelle qui prend trop de temps, des données éparpillées dans plusieurs fichiers, un service que vos clients réclament.
- Qui va utiliser l’outil ? Vos salariés, vos clients, vos partenaires, le grand public. Sur ordinateur, sur téléphone, sur le terrain sans réseau.
- De quel type de solution avez-vous besoin ? Un site web, une application web, une application mobile, un logiciel sur mesure ou simplement le paramétrage d’un outil existant. Si vous hésitez, dites-le : c’est justement une question à trancher avec le prestataire.
- Existe-t-il déjà un logiciel du marché qui fait le travail ? Si oui, pourquoi ne vous convient-il pas ? Cette réponse est très utile pour cadrer le sur-mesure.
- Quelles fonctionnalités sont indispensables dès la première version ? Et lesquelles peuvent attendre.
- Quel budget pouvez-vous mobiliser, et pour quand ? Y compris la maintenance les années suivantes.
- Qui, chez vous, pilotera le projet ? Il faut une personne disponible pour répondre aux questions et valider les étapes.
Inutile de connaître les technologies pour répondre. Le choix entre deux frameworks (Flutter ou Ionic pour une application mobile, par exemple) revient au prestataire, qui doit vous l’expliquer simplement. Votre rôle est de décrire le besoin, pas la solution technique.
Que mettre dans le brief de votre projet ?
Le brief est le document de départ que vous envoyez au prestataire. Il n’a pas besoin d’être long : deux à cinq pages suffisent souvent pour un premier échange. Il sera complété lors des rendez-vous, puis, si le projet se confirme, transformé en cahier des charges détaillé. Pour aller plus loin sur ce second document, on a détaillé la méthode dans notre article sur la rédaction d’un cahier des charges d’application web.
1. La description générale du projet
Résumez en quelques phrases ce que doit faire le logiciel, pour qui et pourquoi. Soyez concret. N’écrivez pas « je veux une application pour le service client de ma banque », écrivez plutôt « je veux une application mobile qui rappelle au client ses échéances de paiement et lui permet de consulter le solde de son compte ». Indiquez aussi l’état du projet : simple idée, maquettes existantes, première version à reprendre.
2. Les utilisateurs (personas)
Qui utilisera le logiciel, et dans quelles conditions ? Une application destinée à des personnes âgées ne ressemblera pas à une application pensée pour des étudiants. Un outil utilisé par des techniciens sur un chantier n’a pas les mêmes contraintes qu’un tableau de bord consulté au bureau. Décrivez deux ou trois profils types, avec leur niveau d’aisance numérique et leur objectif principal.
3. La liste des fonctionnalités, classées par priorité
Listez ce que l’outil doit permettre de faire, sous forme de phrases simples (« un commercial peut créer un devis depuis sa tablette »). Classez chaque fonctionnalité en trois niveaux : indispensable dès la première version, souhaitable, et à prévoir plus tard. Ce tri est ce qui permet au prestataire d’estimer une première version réaliste et de proposer, si besoin, un produit minimum viable plutôt qu’un projet trop gros d’emblée.
4. Les références et les maquettes
Citez des applications ou des sites dont vous aimez le fonctionnement, en précisant ce qui vous plaît. Si vous avez des croquis, même sur papier, joignez-les. Ce n’est pas obligatoire : un prestataire sérieux sait mettre en forme une vision décrite en mots, et dispose souvent d’un designer pour les maquettes.
5. L’existant et les intégrations
Le logiciel doit-il échanger des données avec vos outils actuels (ERP, CRM, logiciel de comptabilité, site e-commerce, outil de paie) ? Indiquez leurs noms et versions, et si une documentation d’API existe. C’est souvent ce point qui fait varier le plus l’estimation, car une intégration mal anticipée peut changer toute l’architecture du projet.
6. Les contraintes
Données personnelles ou sensibles (santé, données bancaires), hébergement imposé, accessibilité, langues, volume d’utilisateurs attendu, obligations propres à votre secteur. Mieux vaut les signaler dès le départ que les découvrir à la recette.
7. Le budget et le calendrier
Donner une fourchette de budget n’est pas se mettre en position de faiblesse. Cela permet au prestataire de vous dire tout de suite si le projet est faisable dans cette enveloppe, et quelles fonctionnalités garder pour y parvenir. Précisez aussi la date à laquelle l’outil doit être utilisable, et si elle est liée à un événement (salon, saison, fin d’un contrat logiciel). Pour vous faire une idée des ordres de grandeur, notre article sur le coût de développement d’une application web détaille ce qui fait varier le prix.
Brief, cahier des charges, spécifications : quelle différence ? Le brief est la présentation initiale du besoin, rédigée par vous. Le cahier des charges formalise ce besoin en détail et sert de base au devis. Les spécifications (fonctionnelles puis techniques) décrivent précisément comment le logiciel fonctionnera ; elles sont souvent rédigées avec le prestataire, voire par lui.
Comment choisir le bon prestataire ?
Trouver une société de développement qui comprend vos enjeux est un défi en soi. Comparez au moins deux ou trois prestataires sur les critères suivants :
| Critère | Ce qu’il faut vérifier |
|---|---|
| Références | Des projets proches du vôtre (taille, secteur ou type d’outil), idéalement consultables en ligne. Demandez à parler à un ancien client. |
| Compétences | Les technologies maîtrisées, et surtout la capacité à expliquer pourquoi elles conviennent à votre projet. |
| Design et UX | Qui conçoit les écrans et les parcours utilisateurs ? Un logiciel techniquement solide mais pénible à utiliser ne sera pas adopté. |
| Méthode | Découpage en étapes, fréquence des démonstrations, outil de suivi, environnement de test (préproduction) accessible. |
| Interlocuteur | Une personne identifiée qui suit votre projet du début à la fin et répond dans des délais raisonnables. |
| Devis | Détail par lot ou par fonctionnalité, hypothèses écrites, ce qui est inclus et exclu, conditions de paiement. |
| Après la mise en ligne | Garantie, maintenance, hébergement, mises à jour de sécurité, tarif des évolutions. |
| Propriété et réversibilité | Accès au code source, cession des droits, documentation, possibilité de changer de prestataire. |
Le prix compte, bien sûr, mais comparez des devis qui couvrent le même périmètre. Un devis nettement plus bas cache souvent des fonctionnalités mal comprises, une absence de tests ou une maintenance non chiffrée.
Comment se passe le premier contact ?
La prise de contact se fait généralement par e-mail ou via le formulaire du site du prestataire. Dans ce premier message, présentez-vous en quelques lignes, indiquez le type de projet, votre fourchette de budget et votre calendrier, et joignez le brief s’il est prêt. Si votre projet n’en est qu’au stade de l’idée, dites-le aussi : un bon prestataire vous aidera à combler les zones floues ; si le projet est déjà avancé, il vous signalera les ajustements nécessaires pour le rendre viable.
Tous les prestataires ne fonctionnent pas de la même façon. Certains se spécialisent sur quelques technologies, d’autres refusent les projets aux livrables trop flous. Un brief clair augmente nettement vos chances d’obtenir une réponse rapide et une estimation sérieuse.
Ensuite viennent en général un ou plusieurs rendez-vous de cadrage, où le prestataire pose ses questions, puis une proposition (estimation, planning, méthode). Pour un projet complexe, il peut proposer une phase de cadrage payante, voire une preuve de concept pour lever un doute technique avant de s’engager sur l’ensemble. Préparez vos propres questions pour ces échanges :
- Quels projets comparables avez-vous réalisés ?
- Qui travaillera concrètement sur le projet ?
- Comment verrai-je l’avancement, et à quelle fréquence ?
- Comment sont traitées les demandes de modification en cours de route ?
- Que se passe-t-il après la mise en ligne (bugs, mises à jour, hébergement) ?
- Qui sera propriétaire du code, et pourrai-je le récupérer ?
Chez Osmova, le premier contact se fait par e-mail à contact@osmova.com ou via notre formulaire de contact. Si votre besoin porte sur un outil métier, un extranet ou une plateforme, vous trouverez notre façon de travailler sur la page consacrée à nos applications web sur mesure.
Quels points vérifier dans le contrat ?
Une fois le prestataire choisi, quelques points méritent une attention particulière avant de signer.
La propriété du code et la cession des droits
En droit français, les droits sur un logiciel créé par un salarié dans l’exercice de ses fonctions reviennent à l’employeur (article L113-9 du Code de la propriété intellectuelle). Cette règle ne s’applique pas à un prestataire extérieur : le fait de payer le développement ne vous rend pas automatiquement titulaire des droits. Il faut une clause de cession, et l’article L131-3 du même code exige que chaque droit cédé soit mentionné distinctement et que la cession soit délimitée quant à son étendue, sa destination, son lieu et sa durée. Faites vérifier cette clause par un juriste si le logiciel est stratégique pour vous.
Les données personnelles
Si le logiciel traite des données personnelles pour votre compte (clients, salariés, patients), le prestataire agit comme sous-traitant au sens du RGPD. L’article 28 impose alors un contrat écrit qui précise notamment l’objet, la durée et la finalité du traitement, les mesures de sécurité et le sort des données à la fin de la prestation.
La recette, la garantie et la maintenance
Le contrat doit décrire comment vous validez le logiciel (la recette), pendant combien de temps les anomalies sont corrigées sans frais, et ce que couvre la maintenance ensuite : mises à jour de sécurité, compatibilité avec les nouvelles versions des navigateurs et des systèmes, hébergement, sauvegardes.
La réversibilité
Prévoyez les conditions dans lesquelles vous récupérez le code source, la documentation, les accès (serveurs, noms de domaine, comptes de services tiers) et les données si vous changez de prestataire. C’est ce qui vous protège d’une dépendance subie.
Quelles erreurs éviter ?
- Décrire la solution au lieu du problème. « Il me faut une application mobile » ferme des portes. « Mes techniciens doivent remplir leurs rapports d’intervention sur place, même sans réseau » laisse le prestataire proposer la meilleure option.
- Tout vouloir dans la première version. Un périmètre trop large retarde la mise en service et fait exploser le budget. Commencez par l’essentiel, mesurez l’usage, puis enrichissez.
- Cacher son budget. Vous recevrez des propositions impossibles à comparer, trop ambitieuses ou trop pauvres.
- Choisir sur le seul prix. Comparez les périmètres, la méthode et l’après-livraison.
- Ne pas prévoir de temps interne. Un projet sur mesure demande des réponses, des validations et des tests de votre côté, tout au long du projet.
- Oublier l’après. Un logiciel non maintenu devient vite une faille de sécurité et une source de pannes.
- Négliger la propriété du code. Sans clause de cession claire, changer de prestataire peut devenir très compliqué.
Si votre projet est d’abord un site vitrine ou e-commerce plutôt qu’un logiciel, la démarche est la même mais plus légère : notre article sur le brief pour une agence web vous donnera une trame adaptée.
Questions fréquentes
Faut-il un cahier des charges complet avant de contacter un prestataire ?
Non. Un brief clair suffit pour un premier échange. Le cahier des charges détaillé se construit ensuite, souvent avec l’aide du prestataire, pendant une phase de cadrage.
Faut-il donner son budget au prestataire ?
Oui, au moins une fourchette. C’est ce qui permet de proposer un périmètre réaliste et de comparer les offres sur une base commune.
Indépendant, agence ou ESN : que choisir ?
Un indépendant convient à un projet bien délimité, à condition de prévoir la continuité s’il n’est plus disponible. Une agence réunit en général conception, design et développement. Une ESN est souvent plus adaptée aux grands comptes et aux projets qui demandent beaucoup de personnes. Le bon choix dépend de la taille du projet et du suivi dont vous avez besoin.
Qui est propriétaire du code développé par un prestataire ?
Sans clause de cession écrite, les droits restent en principe au prestataire, l’auteur. Le contrat doit organiser la cession de façon précise, comme l’exige l’article L131-3 du Code de la propriété intellectuelle.
Comment protéger mon idée avant de la présenter ?
Vous pouvez demander la signature d’un accord de confidentialité avant de transmettre les détails sensibles. Dans les faits, une idée seule a peu de valeur : c’est l’exécution qui compte. Présentez d’abord le besoin de façon générale, puis détaillez une fois l’accord signé si nécessaire.
