Nathan Rissot                                    Github  Blog  Contact
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

# Ecrire ses propres outils
24/12/2025 · [ux] [go] [tools]

En temps qu'étudiant en informatique, je suis d'avis qu'écrire ses
propres outils pour "résoudre" des problèmes du quotidien est l'un
des moyen les plus formateurs de progresser.

## I. D'où sort cette idée ?

Durant l'été entre la L2 et la L3, aprés deux ans passé a utiliser le
systeme d'emplois du temps de ma fac, je n'en pouvais plus d'attendre
que les pages chargent, pour pouvoir cliquer sur des boutons
minuscule dans des pages dont l'UX semble être resté coincée aux
standard d'il-y-a 10 ans.

Au cours de ma L2, j'ai découvert le bouton qui permet d'exporter
l'emploi du temps au format .ics, ce qui permet de le ré-importer par
la suite dans une application d'agenda.

Toute les semaines, je télechargait donc le fichier .ics, afin de
l'importer dans mon agenda, avant de retirer manuellement les cours
des autres groupes de TD/TP qui apparaissait sur le planning.

J'aurait pu en rester là, perdre une poignée de minutes une fois par
semaine pour preparer mon agenda...

Mais, un problème majeur reste, l'agenda ne se met pas a jour, il
reste fixé sur ce qu'il est le dimanche soir; ce qui, en connaissant
la passion de certains enseignant a modifier les horaires des cours
du jour pour le lendemain, me forçait quand même à devoir me
connecter tout les soirs sur l'atroce (<- grave dramatisation) site
de la fac pour verifier que mes cours n'ait pas changés.

Une autre option s'ouvrait à moi, au lieu de télécharger le fichier
.ics et de l'importer dans mon application, Google Agenda propose de
simplement copier coller le lien de la ressource pour maintenir à
jour l'agenda.

Cette option n'est pas complètement satisfaisante non plus, car les
cours des autres groupes apparaissent toujours, et cette fois comme
l'agenda est une source externe, je ne peut même pas les masquer.

Aussi, je m'en suis tenu à l'option n°1 pendant ma L2.

Mais, une fois arrivé en L3, j'ai eu une idée superbe : "Et si
j'automatisais le processus ?" (pourquoi est-ce que cela m'a pris 6
mois d'arriver a cette lumineuse réalisation ? mystère.)

![](https://imgs.xkcd.com/comics/automation.png)

[https://xkcd.com/1319/](https://xkcd.com/1319/)

## II. [Trainwreck](https://github.com/TrainWreckOrg/trainwreck)

Pendant cet été j'ai donc ouvert la [page wikipédia du format
iCalendar](https://fr.wikipedia.org/wiki/ICalendar) ainsi que les
fichiers que j'ai téléchargé tout au long de l'année, pour en
decortiquer le fonctionnement.

J'ai été agréablement surpris de découvrir un format très simple, en
plain-text, à base de "balise" ouvrante et fermante et d'identifiant
séparés par des retours a la ligne et des ":".

A partir de la, j'ai écrit un petit script en python:

Telecharger le fichier en .ics -> parser les evenements -> extraire
les evenements de la semaine à venir -> Filtrer les cours qui ne me
concerne pas -> Créer un nouveau fichier en .ics -> importer le
fichier dans mon agenda -> :)

Le problème des la mise a jour automatique restait toujour présente,
mais au moins, recuperer un agenda nettoyé est maintenant quasiment
instantané.

### "Résultat des courses"

- Temps total de l'opération : 1 aprés midi ≈ 4h = **240min**
- Temps "économisé" : 5 minutes par semaine, 26 semaines par année
universitaire : **≈ 130min**


:|


## III. A quoi ça m'a servi ?

A mon avis, l'interêt d'écrire ses propres outils ("outils" ici est
équivalent à "automatisation") ne réside pas uniquement dans le gain
de temps qu'il permettent (ou pas du coup) de réaliser.

L'interêt d'écrire ses propres outils est de se prouver que l'on
peut. se prouver que du code que l'on écrit peut véritablement
devenir utile, même si nous en somme l'unique utilisateur.

## IV. Evolutions du projet

Ce projet de script python ne s'est au final pas arreté la, en le
partageant avec mes amis, ils ont immédiatement vu l'interêt de cet
outil, et tous m'ont demander de leurs envoyer le script pour qu'il
puissent s'en servir aussi

- Temps total de l'opération : 1 aprés midi ≈ 4h = **240min**
- Temps "économisé" par personne : 5 minutes par semaine, 26 semaines
par année universitaire : **≈ 130min**
- Nombre d'utilisateurs : 5
- Temps total économisé : 5 * 130 minutes : **≈ 650min**

:)

Par la suite ce projet a ensuite evolué pour devenir EDT Bot, un bot
discord complet, co-developpé avec [Dany
Dudiot](https://danydudiot.github.io/), puis en une application web
[Edt Bot](https://www.edtbot.fr/), ce qui a monté le temps d'écriture
à un nombre incomptable d'heures, mais qui a monté le nombre
d'utilisateurs a la quasi intégralitée des étudiants de la promo, et
a été une expérience hyper formatrice pour tout les membres de
l'équipe.  

## V. Leçons à retenir de cette expérience:

Pour moi, 3 leçons majeure sont a retenir de cette expérience

### 1. Si tu a un problème, il est probable que quelqu'un d'autre
l'ai aussi

Partager ce Script avec mes amis sur discord m'a permis de voir que
ce que j'ai fait de mon coté pour moi même pouvait aussi servir pour
d'autres personnes.

Le developpement en un bot discord puis une application à permit
aussi de toucher un nombre d'utilisateurs beaucoup plus large que ce
que j'aurais pu imaginer.

Par la suite nous avons appris que d'autres projets de bot discord on
été montés par le passé, certains ont aboutis en un projet
utilisable, d'autres non, aucun n'etait fonctionnel au moment de nos
recherches.

Probablement qu'EDT Bot ira les rejoindres, les besoins en
maintenance régulière sont assez grande, et il parait irréaliste de
trouver des gens qui soit suffisamment fou pour vouloir reprendre le
flambeau, mais il est probable que d'autres projets similaires voit
le jours aprés le notre.

### 2. Identifier clairement les bornes de son problème, et chercher
comment les résoudre

Ce contexte m'a permit d'apprendre a clairement définir le scope d'un
projet avant de s'embarquer dedans, malgrés le fait que le scope du
projet à au final explosé (ahahahah)

Il m'a aussi appris a chercher mes propres réponses, consulter des
docs (aprés l'article wikipédia, je suis allé directement lire le RFC
décrivant la norme pour en savoir plus), et a croire en ma capacitée
à résoudre des problèmes.

### 3. l'UX c'est important

Cette "découverte" a probablement celle qui m'a le plus fait
réfléchir. Qu'est ce qui sépare un bon outils d'un mauvais ? comment
savoir quand automatiser et quand il vaut mieux ne pas perdre de
temps ?

Pour moi la réponse a ces questions réside dans l'UX (User
Experience, Expérience Utilisateur en bon français), cet aspect
souvent ignoré dans les cours de développement web que j'ai pu suivre
à l'Université d'Orléans, mais qui est pourtant capitale dans notre
approche des choses de nos vies.

L'ergonomie d'une solution est directement correlée a l'envie de s'en
servir, le problème du site de la fac n'est pas vraiment son
esthétique "vintage" (péjoratif.), mais bien son UX désastreuse (<-
pas une dramatisation cette fois, c'est de la que vient le nom
"trainwreck" -> "trainwreck of an UX").

Presque une dizaine de clicks, sur des boutons minuscule juste pour
pouvoir voir un résultat insatisfaisant (et incorrect soit dit en
passant, etant donné que les cours des autres filières apparaissait
sur notre emploi du temps...)

En comparaison, ma solution, un simple .cmd *(oui je suis sous
windows, honte a moi, cela va probablement changer bientôt)* qui
lance le fichier python avec les argument en ligne de commande que
j'utiliserait 90% des fois pré-rentrés. 3 clics et un résultat 100%
satisfaisant (c'est plutôt facile quand on fixe ses propres
critères)


Bonus: l'UX n'est pas forcément la même pour tous:

Pour beaucoup de devs le terminal est une seconde maison, il est donc
sensé pour eux d'écrire des outils de type
[CLI](https://fr.wikipedia.org/wiki/Interface_en_ligne_de_commande)
(Command Line Interface : Interface en Ligne de Commande, outils avec
lesquels on interagit avec des commandes dans le terminal, ex: git,
docker ...)

Pour d'autres utilisateurs moins techniques (moins technique n'est
pas péjoratif, tout les utilisateurs d'un outils ne sont pas dev, et
même parmis les dev, tous ne sont pas forcément des fanatiques du
terminal), le fait d'avoir une
[GUI](https://fr.wikipedia.org/wiki/Interface_graphique) (Graphical
User Interface, Interface-Utilisateur Graphique, ex: n'importe quelle
app dans votre barre des taches) est capital pour une UX acceptable.

## VI. [Stationkeep](https://github.com/TrainWreckOrg/stationkeep)

Vous aimez les conventions de nommage ? moi oui c'est pour cela que
tout mes projets en lien avec les emplois du temps on des noms en
lien avec les trains.

Fort de mon experience avec Trainwreck, lorsqu'un nouveau problème en
lien avec les emplois du temps c'est révélé a moi, je n'ai pas hésité
à essayer d'écrire un outils pour le résoudre

L'expérience de Stationkeep fut pour moi un bien meilleur exemple de
scoping sain et de developement d'outils:

### 1. Identification du problème

Les salles du batiment 3IA (le batiment de la composante informatique
à l'université d'Orléans) dispose d'un certain nombre de salle en
libre accès pour les étudiants en dehors des cours.

Nous avons souvent besoin de trouver une salle libre dans le
batiment, que ce soit pour travailler, ou jouer a D&D pendant la
pause du midi.

Le problème est donc d'identifier les horaires d'occupations pour une
journée donnée des salles du batiment pour determiner celle qui
répond le mieux a nos besoins (taille de la période libre, cours dans
les salles voisines, fin du dernier cours dedans pour pouvoir la
récuperer avant d'autres étudiants)

### 2. Identification des utilisateurs

Moi.

### 3. Scope / Scénario d'utilisation

Je tape une seule commande pour lancer le programme, il telecharge
les emplois du temps de toute la fac, filtre les evenements par
salle, puis par horaire, construit un rapport de l'utilisation de
chaque salle, et exporte ce rapport dans un fichier markdown.


Cette définition claire de *mes* besoins et l'expérience obtenue
grace au projet trainwreck m'a permit de plier le projet en quelques
heures encore une fois avec python.

## VII. Leçons a retenir de cette experience

### 1. "If it ain’t broke, don’t fix it"

Ce projet n'etait pas parfait, mais il etait fonctionnel. La premiere
leçons que j'ai appris à été ["If it ain’t broke, don’t fix
it"](https://en.wikipedia.org/wiki/Wikipedia:If_it_ain%27t_broke,_don%27t_fix_it)
(ci ce n'est pas cassé, ne le répare pas) ie, ne perd pas de temps à
améliorer ou "reparer" quelque chose qui fonctionne.

A la place j'ai pris notes des choses que j'ai remarqué en
l'utlisant, et quelques mois plus tard, quand le flot de projets à
rendre et de partiels a réviser s'est calmé, j'ai repris le projet de
zéro et j'ai réglé ces problèmes

### 2. Repartir de Zéro

Ce problème m'a offert ce qui est a mes yeux la chose la plus
précieuse qu'un projet puisse m'offrir. La confiance en soi
nécessaire pour savoir quand il vaut mieux faire le néant, supprimer
l'intégralitée des fichiers du projet et repartir de zéro plutôt que
d'iterer sur du code "médiocre".

J'aurais pu modifier mon code python, mais à la place j'ai choisi
d'utiliser [Go](https://go.dev/) mon nouveau language de
programmation préféré.

Nouvelle codebase, temps de programmation encore plus court que la
première fois malgrés le fait que j'etait encore en train d'apprendre
le language, et un résultat qui, de nouveau satisfait parfaitement le
scope que je me suis fixé.

## VIII. Static Site Generator

Pour le présent site web, j'avais envie de partir sur l'option d'un
Static Site Generator (générateur de site statique), un programme qui
convertit des articles, le plus souvent écrit en markdown, en un
simple site statique utilisant html+css

J'aurais pu utiliser [Hugo](https://gohugo.io/), (qui est aussi écrit
en go), mais j'ai choisi a la place d'écrire mon propre ssg, concu
spécifiquement pour mes besoins, afin d'augmenter ma confiance en mes
capacitées en go.

Pour la conversion markdown -> html, j'utilise l'excellent projet
[pandoc](https://pandoc.org/) en mode html fragment, puis j'ai écrit
un peu d'html+css+js pour les header/footer et la page d'acceuil et
le changement de thème.

Ce projet à été repris à zéro plusieurs fois, en raison de scope trop
grand ou de code que je considére à postériori plutôt médiocre.

Ce projet à été pour moi un moyen de m'assurer ma maitrise des
concepts de base en go, et en ma capacité a utiliser go aussi
efficacement que j'utilisais python.

## IX. Conclusions

Pour moi, écrire ses propres outils est le meilleur moyen de
progresser dans son apprentissage du developpement, et un contexte
très motivant tout en étant assez laxiste: le seul "client" qui doit
être convaincu, c'est vous même.

C'est un exercice important d'évaluation de scope, de developpement
itératif (alternance entre des phases de dev et des phases
d'utilisation/test en prenant en note les points), mais surtout de
shipping de projets.

Finir un outils, c'est finir un projet, bien que potentiellement
plutot simple (un simple script bash, un code python d'une centaine
de lignes), c'est une vraie expérience de dev de A à Z, de la
conception à la publication, potentiellement en une aprés midi ou en
un weekend.

## X. Pour aller plus loin

L'an prochain, j'aimerais m'améliorer dans ma documentation, et dans
la systématisation de la mise en place et de l'utilisation d'un repo
git pour mes projets solo.

Copyright (c) 2025 Nathan Rissot · curl this page:
$ curl https://nrissot.github.io/blog/ecrire_ses_propres_outils.txt
explore: $ curl https://nrissot.github.io/map.txt