Introduction (1/2 à 1 page) :

L’introduction est une partie synthétique et stratégique 🎯. Elle va donner l’impulsion et initier le style de
votre document, aussi n’hésitez pas à passer du temps de dessus pour qu’elle soit la plus claire possible
en considérant, qu’à l’écrit comme à l’oral, les débuts doivent donner rapidement la ligne directrice de
votre pensée pour que votre interlocuteur vous comprenne. La première partie de l’introduction situe le
contexte du projet : votre structure, votre équipe sur le projet, le porteur du projet (vous), votre marché.
La deuxième partie exprime votre besoin en détaillant votre problématique, par exemple, vous ne
pouvez pas traiter toutes les sollicitations de vos clients, votre équipe est débordée par la charge de
travail, un de vos partenaires vous impose d’automatiser vos échanges, vos clients demandent à gérer
eux-mêmes leurs comptes dans un espace clients etc. Vous pouvez, pour illustrer vos propos, ajouter un
ou deux exemples d’applications équivalentes de vos concurrents. La troisième partie anticipe les
résultats attendus : augmentation du nombre d’affaires réalisés, amélioration de la productivité de votre
équipe, augmentation de la satisfaction etc.

L’introduction aide les développeur.se.s à contextualiser le projet et à comprendre votre besoin ce qui
leur permettra être proactif 💡. N’oubliez pas qu’une agence de développement est en mesure de
comprendre toutes vos problématiques si elles sont bien explicitées ^^.

1/ Description fonctionnelle de la solution (3 à 4 pages) :

Il s’agit du gros morceau de votre document et la partie qui doit exprimer précisément votre vision sur la
solution.

Avant de vous lancer dans la rédaction, vous pouvez faire un schéma de l’arborescence (sous forme d’un
arbre) entre les différentes pages envisagées pour votre solution. Ce schéma vous servira de guide 🗂
pour la rédaction (page d’accueil, page profil, page recherche etc.).

En ce qui concerne la rédaction, l’exercice consiste à vous projeter dans votre solution et vous mettre à la
place d’un utilisateur pour décrire une navigation type au sein de votre future solution (comme si elle
existait déjà). Pour chaque page, vous pouvez lister et décrire ce que vous envisagez : pour les
fonctionnalités visibles de l’utilisateur final, les fonctionnalités visibles des administrateurs, et les
fonctionnalités invisibles des utilisateurs (par exemple, un algorithme ou un système d’envoi d’e-mail
automatique etc.). Enfin, si vous envisagez un gros projet, vous pouvez l’allotir en fonction de vos
priorités pour définir une première version avec les fonctionnalités essentielles (=MVP). N’oubliez pas
que votre cahier des charges est un très bon outil pour vous aider à porter votre vision à court terme et
moyen terme pour mettre en place votre stratégie digitale 😉.

2/ Environnement technique (1/2 page) :

Pour cette partie il ne s’agit pas de préconiser une technologie mais de faire l’inventaire des technologies
actuelles de votre système d’information 🖥 (site, CRM, Extranet, app mobile, espace clients, etc.) et
éventuellement des ressources – internes ou externes – qui s’en occupent 👫 (maintenance,
développement, etc). Avec ces informations, le prestataire pourra envisager l’insertion de la solution au
sein de votre système d’information. Et puisque vous êtes en train de faire le tour de vos outils
informatiques existants, vous pouvez en profiter pour regrouper toutes les documentations sur les
technologies que vous avez afin de pouvoir facilement les transmettre à votre prestataire le moment
voulu.

3/ Conditions financières (1/2 page) :

Nous vous conseillons fortement d’indiquer votre budget 💰 à tous vos prestataires afin qu’il vous fasse
une proposition adaptée à vos moyens. En tant que prestataire, nous avons trop souvent entendu : «
Notre budget ? Ça dépendra des réponses que nous avons… » A fonctionner de cette manière, vous allez
sélectionner votre prestataire uniquement sur le prix même si vous vous persuaderez du contraire ^^ et
vous développerez une application non évolutive qui, si elle est livrée, vous coûtera chère en
maintenance… Aussi réfléchissez en amont au budget que vous souhaitez mettre sur le projet et «
indiquez » le dans votre cahier des charges. Cette approche vous permet de dimensionner votre projet
en termes d’engagement pour votre équipe et pour les prestataires sollicités. Le seul risque que vous
avez est d’identifier plus rapidement un budget erroné (trop bas ou trop élevé).

Pour avoir une vision complète des coûts de votre projet, il faut aussi prendre en compte au-delà de
votre budget pour les développements les autres coûts 💲 : le temps homme passé par votre équipe (et
déductible sur un projet CII), le design (les développeurs sont rarement de grands artistes^^ après c’est à
vous de voir), l’hébergement (regardez OVH ou CleverCloud #FrenchTech), les investissements
webmarketing pour faire connaître votre solution, etc.

4/ Planning envisagé (1/2 page) :

Vous pouvez indiquer la date souhaitée pour la mise en ligne de la solution et vos éventuelles
contraintes en terme de planning, par exemple, le lancement de l’application avant une date précise.
Nous vous conseillons de ne pas demander l’impossible en terme de délai à vos prestataires pour éviter
qu’ils n’aient pas les disponibilités pour vous répondre. Vous pouvez considérer qu’un projet web
nécessite généralement entre 2 et 4 mois de travaux pour arriver à la mise en ligne d’une première
version. Aussi, même si vous êtes pressé maintenant que vous vous êtes décidé 😉, vous pouvez compter
entre un et deux trimestres après la fin de l’appel d’offres.

5/ Recommandations graphiques (1/2 à 1 page) :

Cette partie consiste à lister les éléments graphiques 🎨 dont vous disposez et qui pourront être utilisés
par les développeur.se.s : logo, police, charte graphique, UI kit, Design System etc. Vous pouvez ajouter
les éventuelles maquettes de quelques écrans afin d’aider les prestataires à visualiser la solution telle
que vous l’envisagez. Il existe un multitude d’outils sur Internet pour faire des maquettes sans être un
expert, à titre d’exemple vous pouvez utiliser, Balsamiq qui est très simple à prendre en main (vous ferez
des croquis très clairs de votre solution), ou Figma qui est un peu plus compliqué à prendre en main mais
beaucoup plus abouti (vous arriverez à faire un Design proche de votre solution finale).

Conclusion :

Pour terminer votre document, vous pouvez fixer les conditions de l’appel d’offres et particulièrement le
« planning » 📆 de votre appel d’offres : une date de remise des offres, une date de retour suite à
l’analyse des offres reçues, une période pour faire passer des oraux aux prestataires retenus, une date de
prise de décision.