Paul Féry

Parcours

J'ai commencé par l'infrastructure avant d'écrire du code utile à quelqu'un d'autre que moi. Transformer un ancien PC en serveur exposé sur Internet m'a confronté à des questions qu'aucun exercice ne pose : que se passe-t-il quand on publie son adresse IP ? Comment chiffrer l'accès à une console qui ne sait faire que du HTTP ? Comment survit un service quand la machine redémarre à 3 h du matin ?

En 2026, j'ai développé et déployé deux applications métier utilisées quotidiennement dans un atelier de rectification industrielle. Ce sont mes projets les plus formateurs, parce qu'ils ont des utilisateurs réels qui ne sont pas moi : une contrainte de production ne se négocie pas, et un bug se voit.

Ces projets m'ont aussi mis face à des sujets que je croyais théoriques : la concurrence quand deux personnes cliquent en même temps, la gestion de secrets quand un mot de passe se retrouve téléchargeable, l'encodage quand un fichier ment sur sa propre déclaration. Chacun est documenté en détail dans les études de cas.

Ma façon de travailler

• Je documente les décisions, pas seulement le code. Un commentaire qui explique pourquoi une alternative a été écartée vaut plus que dix qui paraphrasent la ligne suivante. Mes projets contiennent des blocs entiers justifiant un choix d'architecture ; c'est ce qui permet à quelqu'un d'autre — ou à moi dans six mois — de ne pas le défaire par erreur.
• J'écris des tests sur les cas qui ont déjà cassé. Pas de course à la couverture : je teste les endroits où un bug est déjà survenu ou qui dépendent d'un comportement subtil (encodage réel d'un fichier, regroupement avec champ manquant, verrouillage concurrent).
• Je préfère supprimer une classe de problème que la rendre difficile. Désactiver l'authentification SSH par mot de passe plutôt que d'en choisir un très long. Faire écrire un seul langage dans un fichier partagé plutôt que d'espérer que deux mécanismes de verrouillage s'entendent.
• J'assume les erreurs par écrit. Un secret exposé, une faille non signalée : c'est documenté dans les études de cas. Masquer ses erreurs empêche d'en tirer quoi que ce soit, et se voit en entretien.

Ce que je cherche

Une alternance en développement pour la suite de mon cursus. Ce qui m'attire le plus : l'intelligence artificielle, et en particulier les agents autonomes. Mes projets m'ont surtout appris à livrer du logiciel qui tient en production ; c'est ce socle que je veux mettre au service de sujets d'IA. La sécurité, elle, reste un réflexe dans tout ce que je construis.

Le code des deux applications en production appartient à l'entreprise et n'est pas public. Je détaille en revanche volontiers l'architecture, les arbitrages et les incidents en entretien : les études de cas de ce site en sont le résumé écrit.

Colophon — comment ce site est construit

Ce site est lui-même un projet. Les choix techniques y sont assumés et vérifiables :

• Aucune dépendance de production, aucun framework. HTML, CSS et JavaScript natifs. Pour un site de six pages, une chaîne de build lourde ajouterait une surface d'attaque (chaîne d'approvisionnement) et un temps de chargement, sans rien résoudre.
• Aucune dépendance de développement non plus. Les tests utilisent le lanceur intégré de Node (node --test), le build est constitué de trois scripts Node d'une centaine de lignes. Le dossier node_modules est vide : rien à auditer, rien à mettre à jour en urgence.
• Un design system en tokens CSS. Couleurs en OKLCH — espace perceptuellement uniforme, qui permet de dériver le thème clair du thème sombre sans recalculer chaque teinte à la main. Typographie fluide en clamp() : aucune media query n'est nécessaire pour le texte.
• Polices système uniquement. Zéro requête réseau, zéro texte invisible pendant le chargement.
• Images en WebP multi-résolutions. L'ancienne page de projets chargeait 12,7 Mo d'images. Une étude de cas pèse aujourd'hui 100 Ko au total, page entière défilée — mesuré, pas estimé. Chaque image est déclinée en trois largeurs sélectionnées par srcset.
• En-têtes de sécurité stricts. CSP interdisant toute ressource tierce et tout style en ligne, HSTS, nosniff, frame-ancestors 'none'. Le serveur de développement applique exactement les mêmes en-têtes que la production — un CSP qui ne casse qu'en production est un CSP découvert trop tard.
• Amélioration progressive. Sans JavaScript, la totalité du contenu reste lisible : les animations d'apparition ne s'activent que si le script a démarré, et prefers-reduced-motion les désactive entièrement.
• Intégration continue. Chaque modification vérifie que les fichiers générés sont à jour, que la syntaxe JavaScript est valide, et qu'aucune page ne viole les invariants d'accessibilité et de SEO (langue, dimensions d'images, textes alternatifs, liens internes valides).