Créer un cahier des charges technique minimal

En amont de la conception d'un projet, il est important de rédiger un cahier des charges afin de mettre noir sur blanc les attentes du clients et les moyens techniques mis en place pour la réalisation, afin de protéger autant le prestataire que le client.

Il est bon de rappeler qu'un cahier des charges est indispensable aux yeux de la justice, même dans le cas d'une méthodologie agile.

Pour la réalisation d'un tel projet, le cahier des charges se décompose en deux parties : le cahier des charges fonctionnel et le cahier des charges technique.

Le premier contiendra la formalisation des attentes du clients (description projet, fonctionnalités, maquettes, etc...), tandis que le deuxième contiendra toutes les spécificités techniques du futur projet.

C'est sur ce cahier des charges technique que je vais me concentrer aujourd'hui, en vous listant les informations principales qui doivent absolument y figurer.

Libre à vous d'ajouter toutes les informations qui vous paraitront nécessaire afin de mener à bien ce projet.

Les supports

Où ce projet sera-t'il disponible ? Sur le web ? Sur le desktop ? Sur une application mobile ? Sur un store public ou privé ?

Toutes ces informations sont de premier ordre car elles conditionneront les langages et technologies à employer. Un projet simple pourra être déployé sur un support, tandis que d'autres pourront être déployés sur de multiples support, le choix de la technologie à adopter aura alors un gros impact en terme de rentabilité du projet.

La compatibilité de version

Une fois les supports déterminés, il faut également ajouter un garde-fou sur les versions minimales à prendre en charge.

Celà doit être soumis à discussion avec le client, en se basant notamment sur les typologies des utilisateurs attendus (pays, écosystème, âge, qualité de vie, etc...).

Attention, une compatibilité de version très ancienne peut imposer des challenges techniques inattendus qui pourraient multiplier les délais !

Les tailles d'écrans

Tous comme les versions des supports, les tailles d'écrans supportés sont importantes à encadrer.

Aujourd'hui la plupart des applications (web, mobile ou desktop) sont "responsives", mais les tailles d'écrans des équipements vont de la montre au poignet jusqu'à l'écran 8K.

L'idéal est donc de renseigner une taille minimale à supporter (4 pouces par exemples), une taille maximale au-delà de laquelle l'interface s'affichera mais ne sera pas optimisée.

Il est aussi possible de renseigner un format minimal d'écran, ainsi que l'orientation !

Format de référence

Mobile-first, Tablet-first ou Desktop-first, ce n'est pas la mode qui défini le format de référence mis en place dans le projet mais l'étude des futurs utilisateurs, de leurs usages et de leurs attentes de l'application.

Typiquement, un panneau d'administration (back-office) sera rarement prévu en mobile-first.

La connectivité

Est-ce que l'application nécessite beaucoup de bande passante ? Ou au contraire doit-elle pouvoir continuer à fonctionner en mode "hors-ligne" ?

Comment se passe la reprise de connexion, et quelle serait la connectivité minimale pour une utilisation correcte du projet ?

La charge utilisateur

Connaître la charge utilisateur nominale et maximale d'un projet permet de prendre des décisions d'architecture, de conception logicielle et dimensionnement des serveurs en conséquence.

Le but n'est pas d'essayer de deviner un chiffre précis, mais d'avoir un ordre de grandeur, exemple :

Si le projet vise à être mis à disposition des collaborateurs de l'entreprise, le nombre d'utilisateur évoluera en même temps que cette dernière. Tandis que si le projet touche le grand public, il faudra pouvoir prévoir les montées en charge liées à la communication derrière le projet.

Hébergement du code

Où l'application va-t'elle tourner, sur quel type de serveur ? Mutualisé ? Dédié ? VPS ? Cloud ? Chez quel hébergeur et dans quel partie du monde ?

Y'a-t'il des contraintes légales ou des demandes clients qui ont orienté ces choix ?

Versioning

Le code est-il sauvegardé avec un outil de versioning ? Si oui quel outils (Git, Mercurial, SVN,...) et chez quels prestataires sont présents les serveurs de sauvegarde (GitHub, GitLab, auto-hébergé,...).

Responsabilité

Il est de bon augure de dégager sa propre responsabilité en cas d'incident au sein de la société d'hébergement, et d'indiquer que toute mission de remise en service dû à une défaillance de l'hébergeur sera soumis à facturation.

Nom de domaine et registrar

Chez quel registrar sera réservé les noms de domaine, ainsi que leurs utilisations (différencier les noms de domaines principaux de ceux qui seront redirigés).

Hébergement des données

En plus des éléments indiqués dans la section précédentes qui sont à ré-indiquer pour les données, il est indispensable de spécifier la ou les stratégies de backup mises en place en cas d'incident.

Vous pouvez également indiqué que toutes demandes du clients contrevenant à la RGPD se verra refusée pour des raisons légales.

L'architecture prévue

L'idéal est de présenter un diagramme macro de l'écosystème dans lequel les données vont transiter contenant les différents serveurs, terminaux et clients logiciels présents.

Base de données, serveur web, serveur de fichier, CDN, application web, native, tout doit-être présent.

Ne pas oublier de mentionner qu'en fonction des besoin du projet ces informations pourront évoluer.

Les technologies logicielles

Pour conclure vous pouvez lister tous les langages, les technologies, les frameworks qui seront utilisés lors de la conception, et éventuellement justifier ces choix, notamment pour aider les futurs mainteneurs du projet à comprendre les enjeux technologiques lors du lancement.