KM4BI

Votre application créée au feeling peut sembler juste et s’effondrer après son lancement : REA montre comment les vraies équipes construisent

REA aide à découvrir les exigences invisibles derrière un logiciel avant de le reconstruire.

Publié le

Une interface qui paraît correcte peut masquer des règles et des dépendances qui ne se révèlent qu’après le lancement. Dans cette démonstration, Nate B. Jones explore REA, un outil qui permet à un agent d’examiner le fonctionnement de logiciels accessibles côté client et d’en expliquer les mécanismes.

Les exemples vont d’un authentificateur Android aux données enrichies du presse-papiers de Notion. Ils montrent pourquoi « copier-coller » ou « ajouter un pourcentage » ne sont pas des spécifications suffisantes : il faut décider quelles relations accompagneront les données, et comment une opération change selon son contexte.

Cette méthode peut éclairer aussi bien la conception d’un outil métier que l’analyse d’un mécanisme précis. L’étude de QuickBooks a, par exemple, inspiré une implémentation indépendante de fonctions comptables en Python et SQLite. Le but n’est pas de reproduire une interface, mais de comprendre les comportements pertinents et de choisir ce qu’il faut construire.

REA est aussi présenté comme un outil d’apprentissage. Une enquête efficace part d’une question concrète et se limite à la profondeur utile. L’inspection décrite concerne le code côté client accessible; elle ne révèle pas le code privé du serveur et ne justifie pas de tenter d’y accéder.

Source