Écrire le cahier des charges d'un site de copropriété pour Claude Code

Le conseil syndical, dont je fais partie, voulait un site privé. Le cahier des charges lui fixe quatre objectifs : que les résidents consultent les informations et les documents de la copropriété, qu'ils signalent un désordre avec du texte, des photos ou des vidéos, que le conseil syndical valide ces signalements, les regroupe et les transmette au syndic, et que chacun suive l'état des réparations.

Ce site sert deux copropriétés voisines qui partagent un parking. Il tourne sur un serveur privé, en préversion protégée par un mot de passe le temps que le conseil syndical le teste.

Un cahier des charges écrit pour un agent

Le projet part d'un cahier des charges d'une quarantaine de kilooctets, en quinze sections : rôles, règles métier, écrans, modèle de données, sécurité, données personnelles, déploiement, tests et questions ouvertes.

Sa première section s'adresse à Claude Code. Elle lui demande de lire tout le document avant de commencer, d'avancer jalon par jalon et de s'arrêter à la fin de chacun pour validation. Elle interdit d'ajouter une fonction hors périmètre sans demander. Et toute valeur marquée « à confirmer » doit devenir un réglage, jamais une valeur écrite en dur dans le code : l'adresse du syndic, la liste des administrateurs, le nom affiché du site.

Les règles métier sont numérotées, de RM1 à RM13. Quand une règle est discutée, on sait de laquelle on parle.

Six jalons, chacun avec un livrable vérifiable

Le travail est découpé en six jalons, du socle technique à la mise en production. Chaque jalon a un livrable vérifiable : « docker compose up affiche une page d'accueil » pour le socle, des parcours de recette numérotés pour les suivants. Les six jalons sont arrivés dans le dépôt le 21 octobre 2026, le jour de la version 1.1 du cahier des charges, avec une série de corrections après la recette à la main des trois premiers. La préversion a été mise en ligne le même jour.

Sont venues ensuite une refonte de l'interface d'après une maquette, puis une longue série de retouches sur la rubrique des documents, pour les assemblées générales, leurs procès-verbaux et les contrats.

Le parcours d'un signalement

Un résident décrit un désordre, choisit le lieu et le thème, joint jusqu'à huit photos ou vidéos. Le conseil syndical valide le signalement ou le refuse, avec un motif envoyé à son auteur. Un signalement validé rejoint un incident : plusieurs voisins qui signalent la même fuite alimentent un seul dossier.

L'envoi au syndic se fait toujours à la main, par un administrateur. Le syndic n'a pas de compte : il reçoit un email avec une référence d'incident et, pour chaque photo, un lien de téléchargement signé, valable trente jours. Les fichiers ne sont jamais joints à l'email.

Ce qui protège les résidents

Un site de copropriété contient des noms, des numéros d'appartement et des photos où peuvent apparaître des personnes ou des plaques. Le cahier des charges en fait des règles précises.

• L'identité du déclarant : seuls l'auteur d'un signalement et les administrateurs voient son nom et son logement. Les autres résidents voient la description et les photos, sans savoir qui a signalé. Le formulaire le dit avant l'envoi.
• Les documents : un propriétaire voit les documents de la copropriété ; un locataire ne voit que ceux qui lui sont ouverts. Le contrôle se fait sur le serveur, pour chaque page et chaque téléchargement, pas seulement dans l'interface.
• Les comptes : un compte n'a accès à rien tant qu'un administrateur ne l'a pas approuvé, et chaque compte est revu une fois par an, pour suivre les départs de locataires et les ventes.
• La conservation : les comptes jamais validés sont supprimés après trente jours, les pièces jointes des signalements refusés après dix jours. Le site fait ce ménage lui-même, une fois par jour.

Connexion, photos et sauvegardes

La connexion se fait sans mot de passe, par un lien reçu par email. Ce lien n'ouvre pas directement la session : il affiche un bouton « Me connecter ». La raison est écrite dans le cahier des charges : les antivirus et les aperçus de messagerie ouvrent les liens tout seuls, et consommeraient un lien à usage unique avant le résident.

Les photos d'iPhone sont souvent au format HEIC, que la plupart des navigateurs n'affichent pas. Le champ d'envoi déclare donc les formats qu'il accepte, et l'iPhone convertit de lui-même les photos en JPEG.

Les sauvegardes tournent chaque nuit. La restauration a été testée sur une base jetable, sans toucher à la production. Le conseil syndical a choisi, et le dépôt l'écrit, de s'en tenir pour l'instant à la sauvegarde hebdomadaire de l'hébergeur pour la copie hors du serveur, en acceptant de perdre au pire une semaine de données.

Un lien de connexion qu'un antivirus ouvre à votre place ne doit pas vous connecter.

Les décisions en route

• Un périmètre écrit : ce qui n'est pas dans la version 1 (sondages, réservations, annuaire des voisins, application mobile) est rangé dans une section des évolutions possibles, et attend.
• Des questions ouvertes écrites : la section 13 liste ce qui restait à trancher, et chaque point réglé y est barré ou complété.
• Des valeurs en réglages : l'adresse du syndic ou la liste des administrateurs changent sans toucher au code.
• Une préversion fermée : le conseil syndical teste derrière un mot de passe avant l'ouverture aux résidents.

Le site est en cours : il reste à l'ouvrir aux résidents.