Rédiger et programmer, même combat ?

Les grandes lignes de la rédaction technique demeurent depuis des décennies : écriture simple, concise et phrases courtes – tout le contraire de ma façon d’écrire au quotidien.
Par chance, je suis également développeur. Cela peut passablement aider. Non seulement pour la logique, la compréhension de logiciels ou de langages dédiés à la production, mais surtout… pour faire court.

Des similitudes

N’allons pas jusqu’à dire que programmer dans un langage-objet est proche de la rédaction technique.
Cependant, on se concentre sur les fonctionnalités. On évite de ré écrire 12 fois le même morceau de code, parce qu’on sait très bien qu’une fois qu’il est opérationnel, on va l’appeler – et pas le copier ! – depuis différents emplacements.
On utilise un Framework, pour ne pas partir de zéro et bénéficier de l’expérience de ceux qui sont déjà passés par là.
Et on va choisir le langage le plus adapté pour le logiciel que l’on développe, donc pour les utilisateurs et pour la plate-forme.

Différents langages, des évolutions et des retours en arrière

Par exemple, j’ai commencé par écrire en C (le pur et dur) et en Visual Basic (moins pur). Le C m’a appris une certaine rigueur algorithmique. Le codage « spaghetti » avec ses renvois dans tous les sens et un travers dans lequel on tombe vite. Idem pour un document : je ne veux pas réécrire – voir page 12, de la documentation spaghetti. Et le Visual Basic m’a montré que créer une jolie interface sur la base d’une appli existante, comme Access, c’est super : on se simplifie la vie, on écrit une petite fonction derrière un bouton. Mais quand on change de version… patatras, on peut tout re tester. Ca me fait penser à Word. On change une image et on ne comprend pas pourquoi tout bouge, il faut reprendre tout le chapitre.
Ensuite j’ai découvert OpenRoad – ça ne me rajeunit pas. Ce langage, ou plutôt cet environnement de développement avait ceci de génial qu’il permettait de développer en objet, de voir mes données persister, de collaborer et donc de bénéficier dans un même référentiel du code, des fenêtres des collaborateurs, de notes et de différentes versions.

Parenthèse sur la persistance des données, c’est simple : on aimerait que ce qu’on a mis dans notre formulaire soit stocké en base de données, dans un fichier, etc.

Parenthèse fermée; un tel environnement avec une même culture d’entreprise, une même façon de travailler, des clients industriels, c’est le génial.
C’est formidable pour un développeur et pour toute personne qui n’aime pas refaire 36 fois les mêmes choses. Les routines de tests sont intégrées, on évite les erreurs, on se sert dans la bibliothèque et on se concentre sur ce qu’on sait faire, créer. Créer rigoureusement et dans un but bien précis, mais tous ceux qui aiment résoudre des problèmes concrets me comprennent. La routine, c’est fini.

Les outils 4×4

Le temps avance, Borland avait déjà inventé le premier RAD grand public (Rapid Application Developpement), Microsoft Visual Studio prend de l’ampleur, Java permet de n’écrire que dans un langage pour plusieurs plates-formes sans modification et PHP perce de plus en plus. Disons que nous sommes autours de 2006, un éditeur vient d’ailleurs de faire progresser son outil s’approchant de très près d’OpenROAD.

Depuis, j’ai malgré tout un sérieux petit doute dans un coin de ma tête ; PHP c’est génial. C’est très avancé, de nombreux Frameworks existent, un pourcentage énorme du web et des applications fonctionnent avec… mais… créer une même interface avec persistance de données (très basic : une fenêtre et je saisis la liste de mes contacts) reste toujours et encore visuellement très peu abouti.

Symphony, Yii2 (pardon, ce sont des Frameworks faits pas des génies pour travailler vite et bien), sont tout de même très éloignés de Visual Studio. Je passe les Docker’s et autres qui permettent de séparer le soft des données et bien plus. Mais ça me chiffonne encore, pourquoi faut-il remettre les mains dans le code quand ce n’est pas utile ? Ce n’est vraiment pas utile quand on crée une interface web. Est-ce que vous utilisez de nouveau un langage de codage pour mettre en page un fichier Indesign ? Evidemment non.

Les puristes me jetteront la première pierre et les suivantes : « on maîtrise mieux », « ce n’est pas fait pour les noobs », etc.

Mettons cela en regard de la rédaction et la communication technique :

Utiliser le bon outil : Bien, je veux que mon contenu soit bien séparé de ma mise en page pour le réutiliser. Évitons de suite Word (Visual Basic), c’est joli, plein de boutons et de fonctions, et on pense que tout le monde maîtrise. Certainement pas, on perd du temps au moindre petit écart, et reprendre du contenu – texte ou image – n’est clairement pas facile, sauf « copier – coller ».

On choisit pour cela un outil qui s’éloigne d’une jolie interface et on passe à XMetal ou d’autres (j’en ai développé un sympa donc je parlerai : Synthetik). Très, mais alors très vite, on se rend compte que c’est finalement plus simple, même si la personne qui passe derrière vous aura tendance à dire « ben moi, j’aimerai pas faire ce que tu fais ». Si, tu aimerais parce que c’est le bon outil.

Utiliser le bon langage : On ne parle pas de C++, Java ou de l’anglais et du français. On s’exprime simplement, clairement.

« Veuillez presser le bouton pourpre de sorte qu’il change de couleur de manière intermittente » contre « Pressez le bouton rouge jusqu’à ce qu’il clignote ». De même, on n’explique pas ce qu’est une clé de 12 à un mécanicien, on lui indique le couple de serrage et un pictogramme pour l’outil.

Référencer son travail : Oui, et là on peut faire les choses simplement ; « Copie_fichier_travail_nov_jeanpaul.xml » ou « 211001_FR_enroulage solenoide_1245_v003_JPC.xml » suffit déjà amplement dans bien des cas : date à l’envers pour un tri facilité – j’ai ma dernière date de modification, la langue, la référence de la BOM pour retrouver l’assemblage, la version et l’auteur. Dans le nom du fichier, tout simplement. On peut faire bien mieux, mais c’est déjà un très bon début.

Rendre son contenu élégant : La réponse est plus nuancée. Il est capital que le client voie votre travail sous son meilleur jour, quelque soit le support et lorsque l’on code, quelque soit la taille de l’écran aussi. Le contenu le plus abouti a besoin de belles images, d’une belle mise en page. Dans ce cas, pour que le contenu soit bien séparé de l’affichage, la mise en forme devient un peu plus ardue.

On se retrouve avec notre PHP. Ici, on parle de feuilles de style superposées, de CSS. Ce n’est pas la mer à boire, mais c’est peu visuel. Tout de même, on ne va pas reprendre nos fichiers et les coller dans Indesign, on gâcherait trop d’efforts.

Je vais donc faire un article sur les CSS et le balisage séparément.