Salut et bienvenue sur ce nouvel épisode du Codecast de Code Garage,
je m'appelle Nicolas Brondin-Bernard
et aujourd'hui on va parler d'un sujet qui est le cahier des charges technique
et je vais vous présenter une version minimale de ce cahier des charges.
Alors, en amont de la conception d'un projet,
il est évidemment important de rédiger ce cahier des charges
pour mettre noir sur blanc les attentes du client
et les moyens techniques mis en place pour la réalisation.
En réalité, ça sert autant à protéger le prestataire que le client.
D'ailleurs, il est bon de rappeler, parce qu'on l'oublie souvent,
qu'un cahier des charges est vraiment indispensable, même aux yeux de la justice
et même quand on est dans le cas d'une méthodologie agile.
Il y a, je vous mettrai dans les liens de l'épisode,
une affaire précédente ou une société de service a perdu contre son client
parce que justement, il n'y avait pas de cahier des charges.
Donc pour la réalisation d'un projet, le cahier des charges se décompose en deux parties.
Il y a le cahier des charges fonctionnel et le cahier des charges technique.
Alors, le premier cahier des charges fonctionnelle,
il va justement contenir la formalisation des attentes du client.
Donc la description du projet, les fonctionnalités, des maquettes, etc.
Alors que le deuxième, ça contiendra toutes les spécificités techniques du futur projet
et c'est sur ce cahier des charges technique que je vais me concentrer aujourd'hui
et je vais essayer de vous lister les informations principales
qui doivent figurer dans ce cahier des charges.
Après, si jamais vous en avez un à faire vous-même,
et bien libre à vous d'ajouter toutes les informations qui vous paraissent nécessaires
pour que le projet se passe bien et que vous ayez bien formalisé tout.
Alors évidemment, ce podcast aujourd'hui, il est un petit peu à destination,
soit des gens qui sont entre la gestion de projet et le développement,
mais il est également pour les freelance,
parce que en tant que freelance, quand vous travaillez sur un projet,
un nouveau projet de A à Z,
il vous faut un cahier des charges technique.
Alors la première grande partie de ce cahier des charges,
ça va concerner les supports.
Où est-ce que ce projet sera disponible ?
Est-ce que ce sera sur le web, sur un desktop,
donc en tant que l'application desktop,
sur une application mobile,
est-ce que ce sera sur un store public, un store privé, etc.
Toutes ces informations sont vraiment de premier ordre
parce qu'elles conditionnent les langages et les technologies à employer.
Donc un projet simple, ça pourrait être déployé sur un seul support,
alors que certains projets seront déployés sur plusieurs supports
et donc le choix de la technologie à adopter
aura un gros impact en termes de rentabilité du projet notamment.
Ensuite, il y a la compatibilité de versions.
Quand on a déterminé les supports,
il faut également ajouter un garde-fou
sur les versions minimales à prendre en charge.
Parce que si jamais vous avez une compatibilité,
pardon, IE7 sur le web,
ça va en fait faire monter le budget du projet en flèche
parce que la complexité est vraiment autre
et il faut trouver des gens spécialisés là-dedans.
Alors ça, ça doit être soumis à discussion avec le client, absolument,
en se basant sur notamment la typologie des utilisateurs qui sont attendus.
Le pays, l'écosystème, l'âge, la qualité de vie,
éventuellement les entreprises dans lesquelles ils travaillent si jamais c'est un outil pro,
puisque certaines entreprises ont un parc unifié sur des technos
qui sont parfois anciennes, etc.
Ensuite, il faut parler de la taille d'écran.
Donc là, c'est un autre grand point après les supports, c'est les tailles d'écran.
Parce que toutes les versions des supports
ont des tailles d'écran différentes qui sont supportées,
à part quelques spécifiques comme les iPad ont moins de tailles d'écran
et encore, c'était vrai à l'époque, c'est beaucoup moins vrai maintenant.
Mais donc, il faut vraiment prendre ça en compte.
Aujourd'hui, la plupart des applications, que ça soit web, mobile ou desktop,
sont responsives, ça adapte.
Mais les tailles d'écran des équipements, aujourd'hui, ça va de la montre jusqu'à l'écran wikia.
Donc, l'idéal, c'est de renseigner une taille minimale à supporter.
Je ne sais pas, 4 pouces par exemple, qui est un petit écran de téléphone.
Et une taille maximale au-delà de laquelle l'interface s'affichera,
mais ne sera pas optimisée.
Alors, il est possible de renseigner un format minimal d'écran,
mais aussi une orientation, parce que l'orientation va jouer.
Et la dernière caractéristique du projet à prendre en compte au niveau de la taille des écrans,
c'est le format de référence.
Ça, c'est plus en termes de design, mais il y a aussi de l'implémentation derrière.
C'est est-ce que le projet va être mobile-first, tablet-first ou desktop-first.
Alors, ce n'est pas la mode qui définit le format de référence mis en place dans le projet,
mais c'est l'étude des futurs utilisateurs de leurs usages et de leurs attentes de l'application.
Ça, évidemment, c'est aux clients de le faire, normalement.
Mais en tout cas, il faut que vous ne pas dire là-dessus.
Typiquement, un panneau d'administration, un bac-office,
sera rarement prévu en mobile-first, parce qu'il y aura une frange très minime des utilisateurs
qui vont l'utiliser sur un téléphone.
Donc, on prévoit pour le desktop.
Éventuellement, si vraiment c'est nécessaire,
on fait en sorte qu'il soit visible et potentiellement un peu utilisable sur téléphone,
mais on ne va pas faire en sorte que tout soit optimisé.
Ensuite, on a la connectivité.
Est-ce que l'application nécessite beaucoup de bandes passantes,
ou au contraire, est-ce qu'elle doit pouvoir continuer à fonctionner en mode hors-lig?
Pour le coup, ça, c'est des questions qui vont plus toucher certains types de projets que d'autres,
notamment les applications mobiles, parce que les applications mobiles, évidemment,
quand on est sur sa 4G dans un transport en commun, peu importe,
on va avoir une connectivité qui va être très inégale,
des fois avec beaucoup de bandes passantes, des fois très peu de bandes passantes,
des fois plus rien du tout.
Donc, il faut également aussi prévoir comment se passe la reprise de connexion,
ou est-ce qu'il n'y a pas besoin justement de cette reprise de connexion,
quelle sera la connectivité minimale pour une utilisation correcte du projet.
Donc, ça, c'est pareil, ça va être à inclure dans le cas des charges,
parce que, techniquement, ça va induire du code, ça va induire des contraintes,
ça va induire plein de choses.
Et donc, si ce n'est pas prévu en amont et que ça arrive au milieu du projet,
on va avoir une vraie grosse surprise.
Donc, c'est mieux que ça soit prévu dans le cas des charges d'origine.
Ensuite, la charge utilisateur.
Alors, la charge utilisateur nominale,
celle qui est moyenne, pas un pic d'utilisation,
justement, une utilisation normale,
et aussi le pic maximal d'utilisation d'un projet,
même s'il est théorique,
ça permet de prendre des décisions d'architecture,
de conception logicielle et de dimensionnement des serveurs,
justement, en conséquence de cette charge utilisateur.
Le but, comme je l'ai dit, c'est pas d'essayer de deviner un chiffre précis,
mais c'est d'avoir un ordre de grandeur.
Par exemple, si le projet vise à être mis à disposition des collaborateurs d'une entreprise,
le nombre d'utilisateurs, normalement, il évoluera en même temps
que le nombre de collaborateurs de cette entreprise.
Alors que si le projet touche le grand public,
il faudra pouvoir prévoir des montées en charge liées à la communication derrière le projet,
si jamais vous passez aux JTTF.
Ça, selon le projet, soit on va se dire de toute façon,
on n'attendra jamais une taille qui est vraiment critique en termes techniques,
ou alors ça peut arriver et il faut le prévoir en un moment.
Ensuite, il y a l'hébergement du code.
Où est-ce que cette application, ce code va tourner,
sur quel type de serveur mutualisé, dédié, VPS Cloud,
chez quel hébergeur et dans quel parti du monde,
est-ce qu'il y a du CDN ou peu importe.
Et surtout, est-ce qu'il y a des contraintes légales
ou des demandes clients qui ont orienté ses choix.
Voilà, ça c'est important parce que vous n'avez pas toujours du code serveur,
si c'est une application qui n'avait que du code client dans une application mobile,
l'hébergement du code, on va dire, ne se réfléchit pas vraiment,
mais il y a plein, enfin la plupart des projets même,
ont héberge du code chez un hébergeur et donc il faut penser en amont,
même quitte à ce que ça change plus tard, c'est pas très grave,
au moins vous avez une trace et une trace de la décision et du pourquoi de la décision.
Évidemment, pour tout ce qui touche au code,
on a plusieurs choses à penser, c'est le versioning.
Le code, est-ce qu'il est sauvegardé avec un outil de versioning ?
Quels outils ? Geat, Mercurial, SVN, peu importe.
Et chez quelles prestataires sont présents les serveurs de sauvegarde ?
Est-ce que c'est GitHub, GitLab, est-ce que c'est de l'auto héberger également ?
Mais on a aussi la responsabilité autour du code.
Il est vraiment important, enfin, il est important,
c'est conseiller justement de dégager sa responsabilité,
sa propre responsabilité en cas d'incident avec la société d'hébergement.
Parce que si jamais vous avez une société d'hébergement qui a un gros prème,
on en a vu des incidents chez OVH, chez plein d'hébergeurs,
il ne faut pas que ça vous retombe dessus légalement.
Ok, c'est chiant, vous pouvez avoir à trouver une solution
si le problème dure longtemps, mais il ne faut pas que légalement ça vous retombe dessus.
Donc ça, c'est pareil, si c'est marqué dans les charges techniques,
c'est signé par le client.
Et aussi, par exemple, justement,
si jamais il y a une mission de remise en service
dû à une défaillance de l'hébergeur que vous ne puissiez pas prévoir,
eh bien cette mission, elle sera soumise à facturation.
Parce que, voilà, c'est de l'imprévu.
Ensuite, on a évidemment le nombre de domaines et le registrar.
Donc chez quel registrar sera réservé,
seront réservés plutôt les nombres de domaines,
mais également les utilisations
différenciées les nombres de domaines principaux
de ceux qui serviront simplement pour une redirection
et de ceux qui serviront pour des sous-services, etc.
Ensuite, on a l'hébergement de données.
En plus des éléments que je viens de vous indiquer.
Eh bien, il faut bien réindiquer pour les données,
pas seulement pour le code, parce qu'il est indispensable de spécifier
là où les stratégies de backup mises en place en cas d'incident,
la localisation des données, etc.
Et vous pouvez également indiquer
que toutes les demandes du client
qui contreviennent à la RGPD,
réglementation générale de la protection des données,
se verra refusée pour des raisons légales.
Parce que vous pouvez avoir des clients des fois
qui vous disent, moi je veux absolument qu'on fasse ça
et vous, si vous le mettez en place, vous pouvez être tenu
légalement responsable en tant qu'éditeur logiciel
pour la réalisation de ce truc-là.
Donc là, au moins, c'est marqué dans le contrat
que vous ne pouvez pas faire des choses qui sont illégales.
Et enfin, c'est l'architecture qui est prévue.
Alors, l'idéal, c'est de présenter un diagramme macro,
on va dire, de l'écosystème dans lequel les données
vont transiter avec les différents serveurs,
les terminaux, les clients logiciels, etc.
Donc ça prend en compte la base de données,
le serveur web, serveur de fichiers, CDN,
applications web, natifs, tout doit être présent,
en tout cas dans l'idéal, au moins pour la version initiale
du projet. Et il ne faut pas oublier de mentionner
qu'en fonction des besoins du projet, ces informations
pourront évoluer évidemment.
Et ensuite, pour conclure, vous pouvez lister
tous les langages, les technologies, les frémoires
qui seront utilisées pendant la conception
et éventuellement justifier ces choix, notamment
pour aider les futurs mainteneurs du projet,
que ce soit dans votre entreprise, ou dans d'autres entreprises,
à comprendre les enjeux technologiques pendant le lancement du projet.
Voilà, donc c'est un petit peu... Il y avait beaucoup d'informations.
Si jamais, évidemment, vous n'avez sûrement pas pu tout noter,
moi, ce que je vous invite à faire, c'est de regarder
dans les notes de l'épisode. Je vous ai mis l'article
qui est à l'origine, justement, de cet épisode du podcast.
Vous avez toutes les informations listées une à une,
déjà, donc vous pouvez toutes les récupérer sur l'article.
C'est dans les liens de l'épisode.
Moi, j'espère que vous aurez appris des choses.
Évidemment, là, c'est un cas de charge technique minimal.
Il y a plein d'autres choses qu'on peut mettre.
Je vous ai dit, sentez-vous libre. Il faut que ça puisse vous protéger vous
et que ça puisse protéger votre client en cas de changement imprévu.
Moi, sur ce, je vous donne rendez-vous la semaine prochaine
pour un prochain épisode du podcast,
ou sinon directement sur code-garage.fr
pour retrouver tous nos cours, tous nos articles de blog,
les podcasts et toutes les ressources qu'on met à disposition.
Je vous souhaite de passer une bonne journée et à très vite. Salut !