diff --git a/include/parse.h b/include/parse.h
index dc0e09f..d12d8a4 100644
--- a/include/parse.h
+++ b/include/parse.h
@@ -41,9 +41,6 @@ bool model_get_next_arrow(struct arrow_t *new_arrow,
                           char dimension);
 
 long model_get_state_arrows_count(const char *state_id);
-bool model_get_next_arrow(struct arrow_t *new_arrow,
-                          const char *state_id,
-                          char dimension);
 
 
 
diff --git a/src/main.c b/src/main.c
index 40ef644..2d680fe 100644
--- a/src/main.c
+++ b/src/main.c
@@ -32,15 +32,51 @@
 
 #include "../include/callbacks.h"
 
-/* https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel
- * https://en.wikipedia.org/wiki/Multitier_architecture
+/* La question  < Comment renommer les fonctions ? >
+ *    dépend d'au moins deux questions et d'au moins deux règles :
  *
- * Quel modèle pour l'organisation du client gem-graph ?
  *
- * Quelles structures apparaissent bien individualisables dès aujourd'hui ?
- * Quelles structures (encore à peine ébauchées) ont un développement prévisible ?
- * Quelles interfaces peut-on prévoir, vers quels modules à venir,
- *         afin de garder un code aussi simple et adaptable que possible ?
+ * > Quel modèle pour l'organisation du client gem-graph ?
+ *   https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel
+ *   https://en.wikipedia.org/wiki/Multitier_architecture
+ *
+ * > Quelles structures sont suffisamment individualisées dès aujourd'hui,
+ *   ou ont un développement suffisamment prévisible (modules, interfaces)
+ *   pour qu'on puisse décider de les renommer
+ *                                   (et comment classer et nommer les autres) ?
+ *
+ *
+ * > Ici, les noms doivent être "human-readable" ET "machine-readable.
+ *
+ * > Toute fonction utilisée par un autre module doit
+ *   -  commencer  D'ABORD  par le nom de ce module,
+ *   -  indiquer   ENSUITE  sa nature (get, set, print,...)
+ *   -  et         ENFIN    son objet (STATE, RULES,...)
+ *
+ *   ex: widget_get_RULES_page()
+ *       automat_set_STATE_RULES_DATA()
+ *       on_save_CURRENT_MODEL_before_editing()
+ *       model_get_DIM_VALUE()
+ *       model_get_NEXT_ARROW()
+ *
+ *       'on_'   == callback ('on_'   est un alias de  'callbacks')
+ *       'model' == parse    ('model' est un alias de  'parse')
+ *
+ *
+ * >  selon ces règles,        get_user_tree_model()
+ *    devrait être renommé :   tree_get_USER_TREE_MODEL()
+ *
+ * >  si, comme c'est prévisible, 'state.c' devient un dossier contenant :
+ *    les fichiers 'controls.c', 'camera.c', 'contrasts.c' et d'autres
+ *    alors,                   get_ZOOM_box()
+ *    devrait être renommé :   state_camera_get_ZOOM_box()
+ *
+ *
+ * >>>  nous devons nous choisir des règles de renommage des fonctions qui
+ *      soient conformes aux 'bonnes pratiques' du 'génie logiciel'
+ *      ET soient les plus pertinentes possibles pour notre cas particulier.
+ *
+ *                           (2024-07-09  5h00)
  *
  *
  * 1) Les structures hiérarchiques.
@@ -90,7 +126,8 @@
  *
  * Tous les callbacks sont dans le fichier 'src/callbacks.c'
  * et leur nom commence par: 'on_'
- * (aucun autre nom de fonction ne commence par 'on_').
+ * (aucun autre nom de fonction ne commence par 'on_') ('on_' est un alias).
+ *
  * S'ils deviennent trop nombreux, ils seront répartis
  * dans des fichiers regroupés dans un dossier: 'src/callbacks.c'.
  *                   (ou 'src/callbacks' ?)
@@ -125,8 +162,8 @@
  *
  *
  * Les préférences des utilisateurs devront être prises en compte.
- * leur recueil et leur mémorisation seront probablement des fonctions centrales
- * mais leur mise en oeuvre suivra probalement la voie hiérarchique.
+ * Leur recueil et leur mémorisation seront probablement des fonctions centrales
+ * mais leur mise en oeuvre suivra probalement les voies hiérarchiques.
  *
  * On peut prévoir des préférences concernant l'apparence des widgets,
  *         les traductions, les 'disabilities'; etc.
@@ -137,15 +174,15 @@
  * Comment optimiser ?
  * -------------------
  *
- * Modularité
- *        (définir les interfaces entre modules tôt et précisément)
- * Commenter, faire tester (pas trop tôt, pas trop tard)
- * Tests graphiques, tests unaires, profiling
+ * Modularité  <>  définir les interfaces entre modules tôt et précisément
+ * Commenter   <>  faire tester (pas trop tôt, pas trop tard)
+ * Tester      <>  tests graphiques, unaires, profiling...
  */
 
 
 
 /*         L I S T E   D E S   F I C H I E R S   A   R E N O M M E R          */
+/*                       (en cours, 2024-07-09  5h00)                         */
 
 /* Tous les callbacks sont dans le fichier 'src/callbacks.c'
  * et leur nom commence par: 'on_'
@@ -177,7 +214,7 @@
  *
  *
  *
- * (en cours - 2024-07-08  7h50)
+ * (en cours - 2024-07-09  5h00)
  */