Ce qu'il faut à une plateforme avant le code

Parce qu'une question réglée tôt n'a plus à être réglée plus tard par un développeur, en plein travail. Quand il est écrit comment une facture s'annule ou qui voit le dossier d'un client, la plateforme est construite dès le départ comme votre entreprise l'entend.

La différence se voit nettement dans la refonte de vieux systèmes. Le code est en général correct. Ce qui manque, c'est une description écrite de ce qu'il devait faire. Quand cette description existe, toute discussion sur un « bug » devient simple : nous regardons ce qui est écrit et nous savons tout de suite ce qui est valable.

Noter les réponses prend une ou deux semaines. Cela coûte pourtant bien moins cher qu'une règle découverte au quatrième mois, quand les écrans et les données reposent déjà sur une mauvaise hypothèse. C'est pourquoi notre démarche commence par une étape d'exigences. Vous la validez avant que la structure, le design ou la construction commencent.

On écrit six éléments, et aucun ne demande de langage technique. Le tableau montre chacun d'eux, la question à laquelle il répond et un court exemple de réponse, assez clair pour construire dessus. Une réponse qui tient en quelques phrases simples montre que tout le monde a compris le sujet.

La dernière ligne est la plus importante. Une exigence a de la valeur quand on peut la vérifier. C'est pourquoi nous réécrivons avec vous chaque souhait général, jusqu'à en faire un contrôle précis.

Elles le deviennent en cinq étapes, toujours dans le même ordre. Chaque étape se termine par un texte que vous pouvez lire et valider. La construction commence une fois la cinquième étape validée. Ce qui reste ouvert à ce moment-là est noté comme ouvert, pour que ce soit vous qui décidiez, et non la personne qui construit.

1. Nous parlons à ceux qui l'utiliseront. Nous écoutons le propriétaire de l'entreprise, mais aussi la personne qui s'en servira chaque jour. Elle connaît les exceptions.

2. Nous écrivons les règles en phrases simples. Une règle par phrase. « Un remboursement au-delà d'un certain seuil demande une approbation » est une règle claire, qui peut être vérifiée.

3. Nous définissons les rôles et ce que chacun voit. Un simple tableau de rôles et d'actions repère la plupart des erreurs de droits avant qu'elles apparaissent.

4. Nous notons les limites et les questions ouvertes. Les limites légales, techniques et de fonctionnement tiennent sur une page. Chaque question qui attend une réponse reçoit un responsable et une date.

5. Nous convenons des contrôles d'acceptation. Chaque règle reçoit au moins un contrôle. Vous lisez la liste et vous la validez.

Le résultat est un périmètre écrit qui décrit votre entreprise avec précision. Nos propres outils de construction travaillent à partir de lui. C'est pourquoi le soin apporté à cette étape se voit tout au long du projet.

Cela veut dire que nous choisissons la technologie une fois que nous savons ce dont vous avez besoin. Les exigences disent ce que la plateforme doit faire, combien de personnes l'utiliseront et à quels systèmes elle doit se connecter. Ensuite, nous choisissons les outils qui conviennent à ces données. Nous expliquons par écrit pourquoi nous les avons choisis, pour que vous ayez toujours la justification.

Un petit outil interne pour dix collègues et une plateforme pour des milliers de clients de plusieurs organisations sont deux projets différents, même si les écrans se ressemblent. Le premier demande une installation simple, facile à remettre. Le second demande des données séparées pour chaque client, des règles d'accès soignées et une surveillance. Quand nous savons dès le départ lequel des deux il vous faut, le système a exactement la taille que votre activité demande.

Sur la page plateformes SaaS et applications métier, vous verrez ce que comprend un tel projet. L'étape des exigences est le moyen le plus net de trouver ensemble la bonne solution pour votre cas.

Méritent une attention particulière les exigences qu'aucun écran ne montre : sécurité, accessibilité, gestion des erreurs, remise du projet. En général, personne ne les demande, mais elles changent beaucoup l'usage de tous les jours. Nous les passons en revue une à une dès le début, car elles s'écrivent alors facilement, alors que sur un produit fini elles s'ajoutent à un coût plus élevé.

• Sécurité. Qui peut se connecter, comment les mots de passe sont protégés, que se passe-t-il après de nombreuses tentatives échouées. L'OWASP Application Security Verification Standard est une norme ouverte d'exigences techniques de sécurité. Nous l'utilisons comme liste de contrôle pour voir lesquelles concernent votre plateforme.

• Accessibilité. Si la plateforme doit servir des personnes en situation de handicap, cela s'écrit dès maintenant. Le WCAG du W3C est la référence internationale, avec les niveaux A, AA et AAA. L'objectif devient ainsi une exigence qui peut être vérifiée.

• Gestion des erreurs. Le prestataire de paiement ne répond pas, un fichier est trop gros, l'utilisateur ferme la fenêtre en plein milieu. Pour chaque cas, nous convenons de ce qui se passera exactement.

• Remise du projet. Comment les comptes, le code et les données vous sont remis le jour où le projet se termine.

• Montée en charge. Pas besoin de prévision, juste une question : si les utilisateurs deviennent dix fois plus nombreux, qu'est-ce qui doit continuer à marcher ?

On vérifie plus que ce qu'on imagine. Un périmètre écrit est relu pour y chercher des contradictions. Un tableau de rôles est testé avec de vrais scénarios. Les contrôles d'acceptation deviennent des tests automatiques avant même que la fonction qu'ils vérifient existe. C'est la logique du « le test d'abord » : le contrôle est la spécification elle-même, sous une forme qui s'exécute.

Nous suivons la même approche dans notre propre travail. L'étude de cas du Planner montre comment un cahier des charges écrit devient une application, avec des contrôles à chaque étape et dans un vrai navigateur. Elle montre aussi ce qui devient possible quand les textes sont assez précis pour qu'un outil puisse les suivre.

Si vous avez déjà des notes, un tableur ou un ancien système, apportez-les. Ce sont de précieux matériaux pour le cahier des charges, même désordonnés. Vous pouvez commencer par une demande de projet et nous dire ce que vous savez déjà et ce que vous voulez clarifier avec nous.

Vous décidez de l'objectif, des règles, des données et des priorités, car ce sont des décisions d'entreprise. Nous proposons des solutions, nous expliquons le pour et le contre, et nous notons chaque décision. L'approche technique, c'est nous qui la décidons, une fois les exigences validées, et nous l'expliquons en langage simple.

Ainsi, les responsabilités restent claires. Si une règle doit changer plus tard, un écrit indique qui l'a fixée et pourquoi. La correction devient une discussion simple et sereine. Si un choix technique doit changer, le même écrit montre quelle exigence il sert.