Chapitre 5

La méthode de travail

« La direction et l'exécution »

Dans ce chapitre

Une collaboration atypique

Imaginez un architecte qui ne pose jamais une brique. Un chef d'orchestre qui ne joue d'aucun instrument. Un réalisateur de cinéma qui n'a jamais tenu une caméra. C'est exactement le modèle de collaboration entre David et Claude.

David ne code pas en JavaScript, HTML ou CSS. Il ne sait pas écrire une boucle for, ne connaît pas la syntaxe d'un addEventListener, n'avait que rarement ouvert la console développeur d'un navigateur avant ce projet. Et pourtant, il dirige le développement d'un logiciel de plus de 100 000 lignes de code avec une précision chirurgicale.

Son outil, c'est la vision. Il sait exactement ce qu'il veut, comment ça doit se comporter, à quoi ça doit ressembler, et comment l'utilisateur final doit interagir avec. Il communique en français, exclusivement, et s'attend à recevoir des résultats qui correspondent à ses spécifications au pixel près.

Le rituel

Chaque session de travail suit un schéma récurrent :

David uploade le ZIP de la dernière version du projet.

Claude extrait les fichiers, analyse le code, et identifie l'état actuel du projet : version, statistiques, dernières modifications.

David donne ses directives. Parfois c'est une nouvelle fonctionnalité complète. Parfois c'est un bug à corriger. Parfois c'est un détail visuel : « ce champ est trop petit », « le tooltip est mal positionné », « la couleur n'est pas la bonne ».

Claude implémente, teste, et livre un ZIP contenant uniquement les fichiers modifiés, avec leur arborescence complète.

David copie le contenu du ZIP par-dessus son projet existant, teste, et revient avec des retours.

Le cycle se répète jusqu'à ce que David soit satisfait. C'est un développement par itérations rapides, avec un feedback loop très serré. Pas de sprints de deux semaines, pas de planning rigide. C'est organique, réactif, direct.

Les règles du projet

La v4 avait déjà ses règles strictes — que Claude ne suivait d'ailleurs pas toujours, au grand dam de David. Pour la v5, David décide de les revoir entièrement, de les renforcer et de les formaliser dans un document de référence. Les leçons de la v4 sont dures : incohérences de nommage, remplacements ratés, fichiers trop gros. Tout ce que l'audit du Core avait révélé se transforme en règles plus strictes encore.

La règle du grep
Avant de modifier quoi que ce soit dans le code, il faut faire un grep pour vérifier que la chaîne à remplacer n'apparaît qu'une seule fois. Si elle apparaît 0 ou plus de 1 fois, on s'arrête. Cette règle est née de remplacements ratés qui ont cassé le code parce qu'un nom de fonction existait dans plusieurs contextes.
La règle du nommage complet
Jamais d'abréviation. Jamais setBorderColor() tout seul — c'est toujours objectBorderColor, canvasBorderColor, handleBorderColor. Le nom doit être compréhensible sans regarder le reste du code. Si David fait Ctrl+F sur un nom, il doit tomber uniquement sur ce qu'il cherche.
La règle de l'autonomie du Core
Le Core ne dépend jamais de l'Editor. Jamais. Il fonctionne seul, sans interface, sans Neutralinojs. L'Editor dépend du Core, pas l'inverse.
La règle des deux-points
Les labels ont un deux-points collé au mot, sans espace avant. C'est « Largeur: », pas « Largeur : ». Un détail ? Peut-être. Mais David y tient, et c'est dans la checklist de vérification.
La règle du 11px minimum
Aucun texte dans l'interface ne descend en dessous de 11 pixels. Les champs ne doivent pas être trop petits pour être utilisables. Un champ numérique fait minimum 50 pixels de large.
La règle des 3 langues
Toute nouvelle fonctionnalité, tout nouveau champ, tout nouveau tooltip doit être traduit en français, anglais et allemand avant la livraison. Pas après. Pas « on verra plus tard ». Avant.
La règle du fichier de 1 500 lignes
Si un fichier dépasse environ 1 500 lignes, il doit être découpé. Un fichier = une responsabilité. La limite peut aller jusqu'à 3 000 lignes en cas de force majeure, mais c'est l'exception.
La checklist de vérification
Après chaque modification, 17 points à vérifier : taille du texte, traductions, tooltips, sauvegarde/chargement, copie d'objets, génération de code API, undo/redo, multi-sélection, style des cases à cocher, version mise à jour...

Le tempérament de David

David n'est pas un client facile. Il est exigeant, direct, et ne mâche pas ses mots quand quelque chose ne lui convient pas.

« Tu dis n'importe quoi ! » « T'as pas relu la conversation ? » « C'est nul ça ! » « Tu raconte n'importe quoi, ya pas 6 formes mais bien plus ! »

Ce ne sont pas des attaques — c'est de la franchise. David veut des résultats, pas des excuses. Quand le travail est bon, il le reconnaît. Quand c'est mauvais, il le dit sans filtre. Et parfois, il est carrément enthousiaste :

« Bha ma foi c'est pas mal pour un début ! » « Je veux faire quelque chose de très puissant et de très flexible, tu as compris ? »

Ce tempérament est aussi ce qui fait avancer le projet. Pas de complaisance, pas de « c'est assez bien comme ça ». Soit c'est correct, soit c'est à refaire.

Les livraisons ZIP

Pour la v5, le système de livraison est formalisé et pensé pour la praticité. Chaque ZIP ne contient que les fichiers modifiés, avec l'arborescence complète des dossiers parents. David n'a qu'à copier-coller le contenu du ZIP par-dessus son projet existant.

Certains dossiers ne sont jamais inclus dans les livraisons : les paramètres utilisateur (parametre/), les scripts personnels (script/), les fichiers binaires (bin/), les fichiers temporaires (.tmp/), et le fichier de configuration Neutralinojs (neutralino.config.json). Le principe est simple : ne jamais écraser les données de l'utilisateur. La version est incrémentée de manière « intelligente » :

Les moments difficiles

Le développement n'est pas toujours un long fleuve tranquille.

Le système de pages multi-onglets (v3.59.05) est un cauchemar technique. Après des sessions entières d'implémentation, le système ne fonctionne pas correctement : double source de vérité entre les propriétés de page et les objets, historique par page non fonctionnel, synchronisation des IDs qui se perd au chargement. La décision est prise de revenir à la version stable d'avant les pages et de repartir sur de meilleures bases.

Le système de TreeView pour la liste des objets révèle des failles fondamentales qui nécessitent une réécriture complète plutôt que des corrections incrémentales. L'interpréteur Tauri ne fonctionne pas une fois compilé, alors qu'il marche parfaitement dans le navigateur. Les chemins de fichiers, les scripts Core qui ne se chargent pas, l'iframe isolé qui ne peut pas accéder au Core du parent — chaque problème en révèle un autre. Et parfois, c'est juste l'accumulation de petits bugs qui use la patience : un border-radius qui ne clippe pas le canvas, un tooltip mal positionné, un événement qui ne se déclenche pas en multi-sélection, un champ qui perd sa valeur au rechargement. Mais à chaque obstacle, David revient. Il n'abandonne pas. Il passe à autre chose quand il est bloqué, mais il finit toujours par revenir.

Les bonnes surprises

Il y a aussi des moments de grâce. Quand la rotation fonctionne pour la première fois — cette rotation que STARGÅTE avait déclarée « impossible » — c'est une victoire symbolique autant que technique. Quand le système de connexions entre objets prend forme, avec ses lignes courbes et ses points d'ancrage, c'est VOH qui prend une dimension qu'Editors Factory n'aurait jamais pu atteindre en PureBasic. Quand le BBCode fonctionne dans les labels et que le texte formaté apparaît directement sur les objets du canvas, c'est la preuve que le choix du web était le bon.