Sophién Felkaoui

Une page unique pour un restaurant de burgers : la carte, les horaires, l'accès, et depuis peu la possibilité de composer sa commande. Direction artistique demandée par le restaurant : l'esprit d'un jeu vidéo des années quatre-vingt-dix, néons et coucher de soleil.

• Les 22 burgers sont dessinés, pas photographiés. Un script PHP lit la liste d'ingrédients de chaque recette et empile les couches — pain, steak, cheddar, cornichon — dans l'ordre d'un vrai burger. Modifier une recette et relancer le script suffit à redessiner le bon visuel.
• La commande se termine dans WhatsApp. Le client choisit sa taille, retire ce qu'il ne veut pas, ajoute ses suppléments et son heure de retrait ; le site prépare le message et l'ouvre dans son WhatsApp. Aucun serveur, aucun compte, aucun paiement en ligne — et rien à sécuriser qui n'existe pas.
• Le panier ne recopie aucun prix. Il lit la carte affichée sur la page. Un prix corrigé dans le HTML est aussitôt le bon dans la commande : les deux ne peuvent pas diverger.
• Aucun cookie, aucun traceur, aucune police chargée ailleurs. Rien ne part vers un tiers au chargement, donc rien à déclarer ni bandeau à afficher.
• Sans JavaScript, le site reste entier. La carte se lit, les horaires s'affichent, le numéro de téléphone prend le relais de la commande.

HTML · CSS · JavaScript sans dépendance · PHP pour la génération des illustrations SVG · hébergement mutualisé OVH · déploiement SFTP par script

Une page unique pour un entraîneur qui donne des cours particuliers : son parcours, sa méthode, ses tarifs, et de quoi le joindre. Fond charbon, rouge et or, caractères d'affiche — l'univers des sports de combat, demandé tel quel.

• Rien n'est chargé depuis l'extérieur. La police d'affichage est servie par le site lui-même, pas par Google. Aucun cookie, aucun stockage, aucun traceur : il n'y a donc ni bandeau à afficher ni collecte à déclarer.
• Aucun formulaire, donc aucune donnée à garder. La prise de contact passe par WhatsApp ou Instagram, là où le coach répond déjà. Un formulaire aurait voulu dire une boîte à relever et des messages à ne pas perdre — pour un résultat moins direct.
• Les photos sont converties avant publication. Un script transforme les originaux en WebP aux bonnes dimensions ; les fichiers de départ, lourds, ne quittent jamais le poste et ne sont jamais mis en ligne.
• Chaque fichier porte une empreinte dans son adresse. Une correction de style est visible immédiatement, y compris pour un visiteur déjà venu dont le navigateur aurait gardé l'ancienne version.
• La page tient sur un téléphone sans rien perdre. Vérifié à 375 pixels de large : aucun débordement, aucun défilement latéral.

HTML · CSS · JavaScript sans dépendance · PHP pour la conversion des images · hébergement mutualisé OVH · déploiement SFTP par script

Une application écrite pour apprendre en construisant plutôt qu'en suivant un cours : fiches, documents et suivi d'incidents, en PHP sans framework et sur une base SQLite. Elle m'a surtout servi à traiter les problèmes qu'on ne rencontre qu'en allant au bout.

• Les PDF sont rendus par Chromium sans interface, à partir de la vue d'impression — aucune bibliothèque PHP de mise en page. Le navigateur rendant la main avant d'avoir fini d'écrire, le programme attend un fichier stable, non vide et commençant par l'en-tête PDF avant de continuer.
• Un client IMAP écrit en PHP pur. L'extension imap a disparu de PHP 8.4 ; plutôt que de rester sur une version ancienne, j'ai écrit le dialogue avec le serveur. Un message reçu d'un contact connu devient un ticket.
• Les documents se partagent par lien à jeton, sans compte ni mot de passe pour le destinataire.
• Le temps passé se facture, les notes internes non. La règle est écrite une seule fois, dans le code qui ajoute un message à un ticket — pas dans chaque page qui affiche un total. C'est ce qui garantit que le montant vu par le client et celui de la facture ne peuvent pas différer.
• Un diagnostic vérifie toute la chaîne — base, courriel, rendu PDF, droits des fichiers — et se lance sous l'utilisateur du serveur web, pour tester les vrais droits et non ceux de l'administrateur.

PHP 8.4 sans framework · SQLite · Chromium sans interface · IMAP et SMTP · migrations versionnées
Captures prises sur un jeu de données de démonstration.

Les trois projets ci-dessus partagent un même outillage, construit pour qu'une mise en production soit un geste ordinaire plutôt qu'un moment de tension. Rien d'exotique : treize contrôles automatiques, cent trente tests, et la possibilité de revenir en arrière en une seconde.

• Treize contrôles à chaque envoi. Syntaxe PHP et shell, fins de ligne des scripts destinés à Debian, absence de fichier sensible dans le dépôt — et, pour le site du restaurant, la vérification qu'aucune ressource n'est chargée depuis un serveur tiers et qu'aucun traceur n'est présent. Ces deux dernières sont juridiques : les mentions légales l'affirment, une relecture ne suffit pas.
• Les tests portent sur les calculs, pas sur tout. Un montant facturé avait déjà divergé de trois centimes entre l'écran du client et sa facture. Le test central ne vérifie donc pas une liste de valeurs, mais l'invariant dont ce calcul est né — recopier ce que le code renvoie aujourd'hui validerait aussi bien un bug.
• Le déploiement refuse de partir si les tests échouent, ou si le dossier de travail contient des modifications non validées. Et s'il ne peut pas vérifier, il s'arrête aussi : un contrôle qui se saute en silence fait croire qu'on est couvert.
• Chaque version est datée et conservée. La bascule d'une version à l'autre est une opération unique du noyau — aucune requête ne tombe sur un site à moitié remplacé. Le retour arrière est la même opération, en sens inverse.
• Les données ne sont jamais dans la version. Base et configuration vivent dans une zone partagée, rattachées par un lien. Sans cela, chaque déploiement repartirait d'une base vide.

$ bash deployer.sh app
==> Tests des règles de calcul
    OK (130 tests, 189 assertions)
==> Espace de gestion  →  versions/2026-09-11-0230-3d666a5
    reçu
    en service
    versions gardées : 5

$ bash revenir.sh app
    en service : 2026-09-11-0230-3d666a5
    bascule sur : 2026-09-11-0157-697e82a
    fait — 2026-09-11-0157-697e82a

Git · GitHub Actions · PHPUnit · scripts shell relançables · déploiement atomique par lien symbolique

Une machine nue chez un hébergeur, montée puis durcie à la main : c'est la partie qui rejoint mon métier. Tout est écrit dans des scripts, pas dans une suite de commandes tapées un soir et oubliées ensuite.

• Installation et durcissement en deux scripts relançables. Accès SSH par clé uniquement, sur un port qui n'est pas celui par défaut ; mot de passe et connexion directe en administrateur désactivés ; pare-feu et bannissement automatique.
• nginx et PHP-FPM, TLS par Let's Encrypt, renouvellement automatique, en-têtes de sécurité et durées de cache définis dans des fragments communs à tous les sites.
• Un site tant qu'il n'est pas prêt reste fermé. Le site vitrine est protégé par mot de passe et marqué « ne pas indexer » : publier un site professionnel aux mentions légales incomplètes serait une infraction, pas un détail de calendrier.
• Déploiement en une commande, et une empreinte de fichier dans l'adresse des feuilles de style : personne ne garde une ancienne version en cache après une mise à jour.

Debian · nginx · PHP-FPM · certbot · SSH par clé · pare-feu et fail2ban · msmtp