Des outils qui tiennent

Deux types de projets personnels

Chaque développeur a un GitHub rempli de débuts : expériences, prototypes, intérêts d’un week-end. Moi aussi. Deux projets sont liés à mon travail quotidien : nerve pour le développement, fleetdeck pour le déploiement. Leurs rôles diffèrent. Un assistant de programmation n’est pas un service scolaire en exploitation ; un outil de déploiement n’est pas l’application.

fleetdeck est notre infrastructure de déploiement en Go. Elle automatise des étapes Docker Compose avec Traefik et accompagne les instances Schulmittag séparées. La durée réelle dépend aussi de la configuration, des données et de la coordination. nerve est mon assistant de programmation IA en Rust. Son code est actuellement privé, contrairement au statut mentionné dans la première version de ce texte.

Pourquoi construire soi-même ?

La réponse honnête comporte trois parties.

D’abord, l’adaptation. Notre architecture isolée par établissement est précisément le cas où les plateformes génériques ajoutent coûts et complexité. fleetdeck fait une chose : notre déploiement. Un outil ciblé peut être compris ; un outil universel demande qu’on le croie.

Ensuite, la dépendance. Une plateforme tierce impose tarifs, cycles d’abandon et pannes. Pour un produit budgété annuellement par les communes, nous voulons maîtriser le coût et le comportement de l’infrastructure.

Enfin, la compréhension. Écrire son déploiement change le débogage. Pas de ticket d’assistance ni de boîte noire : il y a du code, que nous avons écrit.

Pourquoi rendre le travail accessible ?

fleetdeck est public sur GitHub, donc son implémentation est examinable. Ce n’est actuellement pas le cas de nerve. Une commune peut comprendre son déploiement dans le code, plutôt que dans un livre blanc.

L’ouverture discipline aussi l’auteur. Un code que d’autres peuvent lire est écrit plus clairement. Comme dans l’enseignement, expliquer ce qu’on construit aide à mieux construire.

La limite du romantisme

Construire soi-même n’est pas une fin. Nous n’écrivons ni base de données, ni système d’exploitation, ni serveur web : nous utilisons volontairement une technique éprouvée. Nous ne créons que ce qui touche à notre spécificité et reste assez petit pour être assumé par deux personnes durant des années.

Même un petit outil demande de l’entretien. Nouveaux besoins, erreurs et changements d’interfaces ne disparaissent pas dans un binaire compact. L’essentiel est de pouvoir assurer durablement ce suivi.

Pour aller plus loin : nerve dans le répertoire des projets et fleetdeck et son code public.