Tester
Un logiciel de pilotage ne vaut que si ses chiffres sont justes et si son vocabulaire est celui des gens qui s’en servent. Les testeurs sont ceux qui le vérifient.
Une démo en ligne, dès la livraison des comptes et des habilitations
Dès la livraison d’EP-03 (comptes, authentification et habilitations, actuellement en cours), une démonstration de Waterfall sera mise en ligne. Aucune installation : un navigateur suffit. Elle s’enrichira à chaque tranche livrée : référentiel, projets et révisions, planification, chiffrage, coûts réels, indicateurs, risques, portefeuille (voir la feuille de route).
Un parcours témoin : vos données restent chez vous
La démo s’accompagne d’un parcours témoin qui couvre les situations métier à éprouver. Vous n’avez à apporter ni données ni fichiers de votre entreprise : il suffit de suivre le parcours et de dire ce que vous en pensez. Ce qui nous intéresse :
- ce qui bloque, surprend ou demande une explication en chemin ;
- le vocabulaire qui sonne faux, ou qui ne se dit pas dans votre métier ;
- un chiffre qui ne vous paraît pas cohérent avec le reste ;
- ce qui manque pour préparer une revue de projet ou un comité.
Pour être prévenu de l’ouverture de la démo, écrivez-nous. Les anomalies se signalent ensuite par un ticket sur GitHub, en français ou en anglais.
En attendant : la maquette
La maquette présente déjà tous les écrans, branchés sur un faux service qui sert les exemples du contrat d’API. Si vous êtes à l’aise avec les outils de développement, vous pouvez la lancer sur votre poste depuis le dépôt (make dev, avec Docker, Node 24 et uv).
Relire la spécification
Chef de projet, contrôleur de gestion, PMO, responsable d’offres : vous connaissez les situations que la spécification doit couvrir. Elle décrit en plus de deux cents exigences comment Waterfall traite un avenant, une provision, une tâche non anticipée, une extraction de l’ERP. Votre lecture est l’une des contributions les plus utiles qui soient : une règle qui ne tient pas devant un cas réel coûte peu à corriger dans un document, beaucoup dans le code.
Quelques questions qui méritent un regard métier :
- Votre façon de traiter les avenants entre-t-elle dans le modèle du budget de référence qui ne bouge que par contrat ?
- Vos provisions pour risques se gèrent-elles comme une réserve tenue hors du budget ?
- La règle 0/100 de la valeur acquise convient-elle à la durée de vos tâches ?
- Vos codes d’imputation de l’ERP permettent-ils le rapprochement par sous-projet ?
Une remarque prend la forme d’un constat : l’endroit visé (un paragraphe ou un identifiant d’exigence), une citation exacte et une proposition de rédaction. Les revues déjà menées montrent à quoi cela ressemble. Si le format vous rebute, une simple description du cas suffit pour commencer : écrivez-nous.
Développer
Le service est écrit en Python (FastAPI), l’interface en TypeScript (Next.js), sur PostgreSQL. Le contrat d’API fait foi, et le travail arrive par lots relus et vérifiés par la chaîne d’intégration. Le guide de contribution décrit les règles, et la page open source présente le dépôt et la pile technique.
Une idée de fonctionnalité passe d’abord par le modèle de ticket « Question or proposal » : elle devient un récit utilisateur quand elle entre dans un EPIC.
Faire connaître le projet
Une étoile sur le dépôt GitHub, un message à un collègue contrôleur de gestion, un lien vers ces pages depuis un cours de gestion de projet : un projet libre vit aussi de ceux qui en parlent.