Construire, maintenir, transmettre

Année 1 · ING3 · Printemps 2025

SAFE — Construire et livrer

Safety Access For Everyone, association de premiers secours de l'ESAIP Aix.

Contexte

SAFE est l'association de premiers secours et de prévention de l'ESAIP Aix. Elle forme les étudiants aux gestes qui sauvent, couvre certains événements de l'école et travaille avec la Croix-Rouge française et le service de secours.

Le bureau voulait disposer d'un support clair avant la fin de l'année scolaire : un site qui présente l'association, ses actions, ses informations pratiques, et qui puisse aussi être montré à des partenaires ou à de nouveaux étudiants.

Je savais déjà que je partirais à Angers à la rentrée suivante. La mission était donc limitée dans le temps : mon objectif n'était pas de rester responsable du site pendant plusieurs années, mais de livrer quelque chose d'utilisable avant l'été et de préparer une passation correcte.

Mission

Ma mission consistait à devenir web lead sur le projet, reprendre le pilotage du site, clarifier le besoin avec le bureau, choisir une solution adaptée, puis livrer un site suffisamment propre pour être utilisé après mon départ.

Le précédent web lead avait abandonné la responsabilité principale de la mission, mais il est resté présent autour du projet. La mission n'était donc pas isolée ; en revanche, j'ai assumé la responsabilité principale de la reprise, du cadrage, des choix techniques, du développement, de la livraison et de la passation.

Démarche

Avant de commencer, j'ai comparé plusieurs possibilités. Le bureau pensait naturellement à des outils comme Canva ou Wix, parce qu'ils sont connus, rapides à prendre en main et rassurants pour une équipe non technique. Je comprenais ce réflexe.

Mais en discutant des besoins futurs, certaines limites sont apparues : ajouter des actualités, créer de nouvelles pages, gérer des inscriptions à des formations, faire évoluer le site avec les années. Une solution très simple aurait permis d'aller vite au départ, mais risquait de devenir bloquante plus tard.

J'ai donc proposé une solution développée sur mesure. L'idée n'était pas de choisir la complexité pour la complexité, mais de construire une base plus durable. J'ai présenté ce choix au bureau comme un arbitrage : un peu plus de travail au départ, mais plus d'autonomie et de possibilités d'évolution ensuite.

Actions réalisées

J'ai piloté la reprise du site avec des camarades : développement, apparence, navigation, adaptation aux écrans mobiles et accessibilité. J'ai aussi mis en place une organisation simple pour que la personne qui reprendrait le projet puisse comprendre comment le site fonctionne.

Les éléments techniques détaillés — Ruby on Rails, SCSS, animations, déploiement, accessibilité, tests de performance — servent ici de preuves du travail réalisé, mais l'essentiel de la mission était ailleurs : transformer un besoin associatif en site réellement utilisable.

Difficultés

La principale difficulté a été d'apprendre en avançant. Je n'avais pas toutes les compétences au départ et il fallait accomplir la mission avant la deadline. Il fallait donc progresser vite, résoudre les problèmes au fur et à mesure et éviter de bloquer le projet sur des choix trop ambitieux.

J'ai aussi appris à parler de technique autrement. Quand je rencontrais un blocage, je ne pouvais pas simplement expliquer le problème avec du vocabulaire de développeur. Il fallait le traduire en conséquences concrètes pour le bureau : ce qui pouvait être livré maintenant, ce qui devait attendre une version suivante, ce qui demandait trop de temps par rapport à la valeur apportée.

C'est un apprentissage important : un ingénieur ne doit pas seulement savoir faire, il doit aussi savoir expliquer, prioriser et rendre ses choix compréhensibles.

Résultat

Le site a été livré et utilisé par l'association pendant ma période de mission.

La mission a été validée par 35 heures Open Badges.

Ce que j'ai vécu

C'était la première fois que je travaillais sur un projet dont le résultat final n'était pas seulement une note. Le site devait vraiment servir à une association. Il devait être lisible, utilisable et suffisamment fiable pour être repris par quelqu'un d'autre.

Cela change la manière de travailler. Dans un projet scolaire, on peut parfois se concentrer sur la démonstration principale. Ici, les détails comptaient davantage : la navigation sur mobile, les informations faciles à trouver, les erreurs à éviter, la clarté pour les futurs responsables. Ce sont ces éléments moins visibles qui font qu'un projet est réellement livré, et pas seulement présenté.

Ce que j'ai acquis

Cette mission m'a permis de progresser sur plusieurs points :

• reprendre le pilotage d'une mission déjà engagée
• cadrer un besoin avec un commanditaire non technique
• comparer plusieurs solutions avant de choisir
• expliquer un choix technique de manière compréhensible
• apprendre un nouvel outil dans une situation réelle
• livrer un site visible et utilisable
• préparer une passation pour que le projet survive à mon départ

Ce que j'ai appris sur moi

J'ai compris que je m'investis davantage quand la responsabilité est claire. Reprendre le pilotage d'une mission laissée en suspens m'a obligé à aller au bout, parce que le projet ne dépendait plus seulement d'un exercice, mais d'un besoin réel.

J'ai aussi compris qu'un choix technique n'a pas vraiment de valeur s'il ne peut pas être expliqué. Avoir une bonne solution ne suffit pas : il faut être capable de dire pourquoi elle est adaptée, ce qu'elle apporte, ce qu'elle coûte, et comment elle pourra être reprise ensuite.

Lien avec le métier d'ingénieur

Avec du recul, ce que je retiens le plus de cette mission, ce n'est pas seulement la technologie utilisée. Ce sont les échanges avec le bureau, les arbitrages, la gestion du temps, la passation et la nécessité de rendre mon travail compréhensible.

Je retrouverai cette mécanique dans le métier d'ingénieur : partir d'un besoin réel, dialoguer avec des interlocuteurs qui n'ont pas le même langage technique, choisir une solution proportionnée, livrer proprement, puis transmettre le projet à d'autres.

Année 2 · ING3 → ING4 · Contribution continue

Wiki Linux — Maintenir et transmettre

Contribution publique de documentation technique, ouverte sur wiki.phitalys.fun.

Le wiki est une contribution publique continue : une ressource technique que je maintiens depuis mes cours systèmes en ING3. Au départ, il s'agissait simplement de notes personnelles. Progressivement, j'ai choisi de les rendre accessibles, parce que je me suis rendu compte que les problèmes que je rencontrais — commandes, configurations, erreurs système, comportements de distributions Linux — pouvaient aussi concerner d'autres étudiants.

Cette contribution complète l'engagement SAFE d'une autre manière. SAFE était un projet associatif avec un bureau, une deadline et un livrable précis. Le wiki est plus discret, mais il s'inscrit dans la durée : il s'agit de maintenir une ressource utile, même sans commande extérieure.

Origine

Le wiki est né pendant mes cours systèmes. J'avais besoin de garder une trace propre de ce que j'apprenais : commandes utiles, configurations, explications, erreurs rencontrées et solutions trouvées.

Au lieu de laisser ces notes dans des fichiers privés, j'ai préféré les organiser dans un espace public. L'idée était simple : si une explication m'avait aidé, elle pouvait probablement aider quelqu'un d'autre plus tard.

Démarche

J'ai mis le wiki en ligne sur wiki.phitalys.fun et je l'ai organisé pour qu'il soit consultable librement. Il n'y a pas de compte à créer, pas de restriction d'accès et pas de monétisation. C'est une ressource ouverte.

L'objectif n'est pas de faire un site complexe. L'objectif est de rendre l'information claire, retrouvable et réutilisable. Pour moi, c'est aussi une manière de mieux apprendre : quand je dois expliquer une commande ou une configuration à quelqu'un d'autre, je suis obligé de vérifier que je l'ai vraiment comprise.

Pourquoi je continue

Le wiki est moins visible qu'un projet comme SAFE, mais il compte dans ma manière de m'engager. Il ne repose pas sur une deadline ou sur une demande précise. Il repose sur une discipline personnelle : documenter correctement ce que j'apprends au lieu de laisser l'information se perdre.

C'est aussi une forme de transmission. Je n'écris pas seulement pour moi, mais pour un lecteur que je ne connais pas, qui arrivera peut-être sur la page parce qu'il bloque sur le même problème.

Difficultés

La difficulté principale est justement l'absence de cadre. Pour SAFE, il y avait une échéance, un bureau, un besoin clair. Pour le wiki, personne ne me relance. Il faut donc maintenir l'effort dans le temps.

L'autre difficulté est de ne pas écrire trop vite. Une note personnelle peut être très courte, presque incompréhensible pour quelqu'un d'autre. Une documentation publique demande plus de rigueur : il faut donner le contexte, expliquer les étapes, éviter les raccourcis et vérifier ce que l'on écrit.

Ce que cette pratique m'apprend

Le wiki m'apprend que documenter fait partie du travail technique. Une solution que je ne sais pas expliquer clairement est souvent une solution que je ne maîtrise pas complètement.

Écrire pour les autres m'oblige donc à mieux comprendre ce que je fais. Cela m'apprend aussi à me mettre à la place du lecteur : quelles informations lui manquent ? où risque-t-il de bloquer ? comment rendre l'explication plus simple sans la rendre fausse ?

Ce que j'ai acquis

• structurer une explication pour quelqu'un qui n'a pas mon contexte
• transformer des notes personnelles en ressource réutilisable
• maintenir une ressource publique dans la durée
• vérifier ma propre compréhension en écrivant
• rendre un savoir technique plus accessible

Lien avec le métier d'ingénieur

Dans le métier d'ingénieur, produire une solution ne suffit pas. Il faut aussi pouvoir l'expliquer, la transmettre et permettre à d'autres de la reprendre. Une documentation claire évite de dépendre d'une seule personne et rend un projet plus durable.

Le wiki me fait travailler cette compétence de manière régulière. Il développe ma communication écrite, ma rigueur et ma capacité à rendre compréhensible un sujet technique. Ce sont des compétences que je retrouverai dans n'importe quelle équipe : expliquer une décision, documenter un système, faciliter une passation ou aider quelqu'un à comprendre un outil.