Une fois que vous avez pu valider votre idée et votre concept avec des utilisateurs potentiels, il est temps de passer à la phase de conception. Cette étape est cruciale pour cadrer précisément votre besoin avant de commencer à faire appel aux professionnels (avec le budget qui va avec).
Cinq documents sont essentiels avant de pouvoir passer à la phase de développement. Vous pouvez en préparer certains par vous-mêmes, d’autres nécessiteront l’assistance des professionnels pour les finaliser, mais dans tous les cas, il faut vous assurer que ceux-ci soient bien finalisés avant de commencer à développer. En effet, ces documents auront une force juridique, ce sont eux qui feront foi auprès du professionnel pour vérifier si une fonctionnalité était bien incluse ou non dans le périmètre de la mission. Ce sont eux (avec également une bonne négociation des conditions de paiement) qui vous protégeront en cas de problème. Nous sommes conscients que cette étape peut sembler difficile pour des porteurs de projet qui n’ont pas forcément l’habitude de cadrer des projets, et les documents que nous proposons ici sont spécialement étudiés pour être accessibles à tous, tant que vous avez une vision claire de votre projet.
Le premier document peut sembler inutile tellement il s’agit d’une étape basique, mais il est pourtant essentiel. Le glossaire est le document qui permet de mettre en place un langage commun, définissant précisément chaque concept, chaque action, présents dans le projet.
En créant votre projet, c’est un nouveau jargon qui va émerger et il est essentiel de le définir pour éviter les malentendus et les incohérences. En effet, c’est quelque chose que nous voyons régulièrement, où certains membres de l’équipe vont utiliser un terme tandis que d’autres vont en utiliser un autre pour désigner un concept parfois légèrement différent. Et pire encore, les usages de chacun peuvent évoluer par la suite du projet.
Ce langage commun a un nom, c’est ce que nous appelons le Langage Universel (Ubiquitous Language en anglais), qui sera consigné dans le glossaire par les porteurs du projet. Il sera par la suite essentiel que dans tous les documents, dans tous les échanges, ces termes soient utilisés. Ce Langage Universel, et donc le Glossaire correspondant, doit être un document vivant, mis à jour au fur et à mesure que le projet évolue, où chaque intervenant pourra aller se référer au moindre doute.
Ce que nous appelons les sortants sont l’ensemble des documents que l’application doit être capable de produire. Ces documents, s’il y en a, sont un bon point de départ pour démarrer la phase de conception. En effet, ce sont des documents que vous pouvez/devez produire par vous-mêmes, en précisant les données attendues à l’intérieur, les formats souhaités, la mise en page, les éléments graphiques… Tout cela étant des éléments que les développeurs ne pourraient pas deviner par eux-mêmes. Mais surtout, ces documents vont contenir des indices importants sur les données qui doivent exister dans l’application, ces documents ne pouvant être générés sans elles. Dans beaucoup de cas, les sortants vont fortement aider les professionnels à vérifier que les documents de conception sont cohérents entre eux, et s’assurer que le cahier des charges est clair avant de démarrer la phase de développement. Il n’y a pas de sortants dans tous les projets, mais quand il y en a, nous considérons qu’il s’agit d’une chance permettant d’être plus clair sur les attendus du projet. Il est très important pour le porteur du projet de les faire avec rigueur, en produisant des documents complets avec des cas réels pour s’assurer que l’équipe de développement comprenne bien l’esprit du document qui doit être généré.
À cette étape, nous rentrons dans le cœur du fonctionnement de la future application. Le schéma des processus est un diagramme illustrant pour chaque “Entité” majeure de l’application, l’ensemble des données contenues à l’intérieur et des actions possibles sur celle-ci. Il s’agit d’un document essentiel pour la phase de développement, car il va permettre de définir les différentes entités qui vont exister dans l’application, les tables et les colonnes qui devront être créées dans la base de données, et surtout les différentes conditions qui peuvent faire évoluer ces données. Il s’agit de l’approche la plus efficace pour spécifier précisément le fonctionnement de l’application et éviter que le développeur, comme on le voit trop souvent, prenne le cas échéant des initiatives importantes en phase de développement pour pouvoir livrer le projet.
Ce document est fortement inspiré du Domain Driven Design, qui est une approche de conception de logiciels qui se concentre sur la modélisation du domaine métier et l’utilisation d’un langage commun entre les développeurs et les experts métier, et qui dispose d’une littérature abondante que vous n’aurez pas de mal à trouver.
Il est recommandé dans un premier temps de faire un atelier Event Storming, là encore une approche qui a été bien théorisée. Cet atelier consiste essentiellement à rassembler toutes les personnes qui vont travailler sur le projet, en essayant de lister l’ensemble des événements qui vont se produire dans l’application. Ces événements sont ensuite classés par catégories, et permettent de définir les différentes entités qui vont exister dans l’application, ainsi que les relations entre elles. Il s’agit d’un travail collaboratif qui permet de s’assurer que toutes les personnes impliquées dans le projet ont une compréhension commune du fonctionnement de l’application. Pour plus d’informations sur comment animer un atelier Event Storming, nous vous renvoyons vers l’article dédié sur le sujet.
Une fois que vous avez pu identifier toutes ces informations, vous pourrez les formaliser dans le schéma des processus. Nous dédions également un article dédié sur le sujet, vers lequel nous vous redirigeons pour plus d’informations sur la manière de le réaliser.
Enfin, il est important de noter que ce schéma doit être mis à jour au fur et à mesure que le projet évolue. Il s’agit d’un document vivant qui doit être régulièrement révisé pour refléter les changements dans le fonctionnement de l’application. Pour faciliter cette action, sachez qu’il est possible avec certaines approches de développements de générer automatiquement ce schéma à partir du code source de l’application. En ayant ainsi une telle autodocumentation, cela permet de s’assurer que le schéma est toujours à jour, reflète fidèlement le fonctionnement de l’application et vous permet à tout moment de reprendre le schéma pour indiquer précisément les évolutions que vous souhaitez apporter à la version actuelle de l’application. Il s’agit d’une approche encore peu répandue parmi les agences de développement mais qui a un réel potentiel et que nous cherchons à promouvoir. Nous reparlerons de cette autodocumentation dans les articles suivants.
Pour cette partie, nous rentrons dans les documents que vous retrouvez traditionnellement dans les propositions des différentes agences. Vous aurez d’ailleurs généralement besoin d’eux pour les finaliser, il ne s’agit pas de documents que vous pourrez faire totalement seul.
Les User Stories sont des descriptions simples et concises du parcours classique d’un utilisateur dans l’application. Pour les illustrer, on invite généralement des “Personas”, qui sont des représentations fictives d’utilisateurs types, pour aider à comprendre les besoins et les motivations des utilisateurs finaux.
La Maquette consiste à créer une représentation visuelle des différents écrans de l’application, en intégrant les éléments graphiques et les interactions utilisateur. Elle est essentielle pour valider le design et l’ergonomie de l’application avant le développement. Pour démarrer, il vous sera généralement demandé de lister différents sites ou applications que vous aimez, en expliquant ce qui vous plaît dans leur design. Il s’agit d’un exercice difficile mais essentiel pour permettre à l’agence de développement de comprendre vos attentes et de vous proposer une maquette qui correspond à votre vision. Vous devrez également réfléchir à la liste des écrans de votre application, avec une schématisation rapide des emplacements de chaque information.
Sur cette base, l’UX/UI designer de l’agence va pouvoir créer une maquette de l’application, en intégrant les éléments graphiques et les interactions utilisateur. Cette maquette sera ensuite reprise dans un document de spécifications fonctionnelles, avec une image de chaque écran et une description précise de chaque élément. [Insérer un exemple d’image avec un numéro pour chaque bloc, chaque numéro étant décrit sous l’image] Nous vous conseillons de bien reprendre chaque description, c’est le document qui servira de référence contractuelle et il ne faut pas hésiter à rajouter toutes les précisions nécessaires pour éviter une fois en phase de développement que l’agence vous annonce que ce n’était pas prévu dans le périmètre de la mission.
Les scénarios de tests sont un complément essentiel aux User Stories. Ils permettent de valider le bon fonctionnement de l’application en simulant des interactions réelles avec le système, en incluant des informations sur les données d’entrée, les actions à réaliser et les résultats attendus.
Ces scénarios sont basés sur les User Stories et détaillent les étapes à suivre pour tester chaque fonctionnalité. En intégrant ces scénarios dès la phase de conception, vous vous assurez que chaque fonctionnalité est testée de manière exhaustive, que les fonctionnalités livrées correspondent bien à ce qui était attendu et cela sera également votre meilleure protection contre les régressions potentielles lors des mises à jour futures de l’application.
Enfin, il s’agit aussi pour vous de vous sécuriser juridiquement pendant la phase de développement. En effet, en rédigeant ces scénarios de tests dès la phase de conception, vous allez pouvoir, comme nous l’évoquons dans les parties suivantes, lier la bonne exécution de ces tests aux conditions de paiement, vous assurant ainsi que l’agence mette en place ces tests automatisés dès le début des développements. Vous devriez inclure dans les conditions contractuelles la possibilité pour vous de rajouter à tout moment de nouveaux tests, vous ne pourrez pas anticiper tous les cas de figures importants dans la phase de conception et des nouveaux scénarios seront une manière efficace de communiquer les différents problèmes que vous aurez lors des essais de chaque itération lors des développements. Ces nouveaux tests devront être dans le périmètre des spécifications fonctionnelles qui auront été signées bien sûr. Mais nous vous recommandons aussi de prévoir dès la phase de conception tous les scénarios de tests que vous pourrez anticiper, afin de montrer votre implication dans le projet et faire comprendre à l’agence de développement le cadre dans lequel elle devra évoluer, sous peine de sanctions imposées par les conditions de paiement.
La phase de conception est déterminante pour transformer votre vision en une solution concrète et performante. En investissant du temps dans la préparation des cinq livrables suivants :
vous posez les bases d’un développement structuré et collaboratif. Cette approche méthodique permet d’éviter les surprises lors de l’implémentation, de réduire les risques et d’optimiser la qualité du produit final.