praxis-debug.net — Application web PHP MVC from scratch

Application web PHP MVC développée from scratch

Qui Vitally Lubin — seule
Quoi Application web PHP MVC (Modèle-Vue-Contrôleur) développée from scratch, hébergée en ligne — portfolio, veille technologique, CV
En autonomie, hébergement Infomaniak
Quand 03/2026 → en cours
Comment Architecture MVC maison en PHP pur, MySQL, déploiement SFTP (Secure File Transfer Protocol), Prism.js pour coloration syntaxique
Combien 9 contrôleurs, 4 modèles, base MySQL avec 4 tables — 15 vues dans app/views/portfolio/ au 16/05/2026 (contre 8 prévues initialement)
Pourquoi Construire une identité professionnelle en ligne et documenter le parcours de formation

Contexte de réalisation

Une réalisation sans commanditaire

praxis-debug.net n'a pas été commandé. Personne ne me l'a demandé. J'ai décidé de le construire parce que j'avais besoin d'un outil qui soit à la fois mon portfolio de BTS et un espace pour documenter mon cheminement intellectuel — pas seulement ce que je sais faire, mais comment j'y suis arrivée.

Le nom du site dit quelque chose de cette posture : praxis (la pratique réflexive, l'action qui se pense elle-même) + debug (corriger, affiner, comprendre pourquoi ça ne marche pas). Ce n'est pas un portfolio vitrine. C'est un outil de pensée qui se documente lui-même.

Le fil conducteur du site est la loi de Conway, formulée par Melvin Conway en 1967 : toute organisation qui conçoit un système produira un design dont la structure est une copie de sa structure de communication. Je l'ai vécue avant de la nommer, lors d'un projet de groupe en BTS en février 2026. Ce site en est la preuve concrète : construit seule, il reflète ma façon de penser — par couches, par connexions, de l'impulsion électrique jusqu'au code.

Techniquement, le choix du PHP MVC (Modèle-Vue-Contrôleur) maison — sans framework — est délibéré. L'objectif n'était pas d'aller vite, mais de comprendre ce que je construisais à chaque étape. L'architecture est documentée dans une documentation de suivi maintenue tout au long du développement, qui a fonctionné comme un journal de bord technique.

Compétences E5 mobilisées

1.1 ✅ Recenser et identifier les ressources numériques

Inventorier les composants du système d'information (matériels, logiciels, données, services) et les documenter pour en assurer la traçabilité et la gestion.

J'ai documenté l'ensemble des ressources du projet dans une documentation de suivi maintenue à jour tout au long du développement : 9 contrôleurs, 4 modèles, 4 tables MySQL (thematique, utilisateur, veille, veille_thematique), les dépendances front (Prism.js, Bootstrap) et la configuration SFTP (Secure File Transfer Protocol). Cette cartographie m'a permis de reprendre le travail d'une session à l'autre sans perte d'information.

Exemple — AccueilController.php, le plus simple des 9 contrôleurs : il illustre le principe MVC à l'état pur, un contrôleur qui délègue immédiatement à sa vue, sans logique métier.

<?php
require_once '../app/views/accueil.php';

1.2 ✅ Exploiter des référentiels, normes et standards

S'appuyer sur des documentations officielles, des normes de qualité ou des standards techniques pour guider ses choix et garantir la conformité des solutions produites.

J'ai appliqué les recommandations OWASP (Open Web Application Security Project — Projet Ouvert sur la Sécurité des Applications Web) pour la sécurisation : fichiers de configuration hors du dossier public, point d'entrée unique (index.php), requêtes préparées via PDO (PHP Data Objects). J'ai utilisé le patron d'architecture MVC comme référentiel de conception, et choisi une licence Creative Commons pour le contenu publié.


1.3 ✅ Mettre en place et vérifier les niveaux d'habilitation

Définir et contrôler qui a accès à quoi : droits, rôles, comptes utilisateurs — de façon à protéger les ressources tout en permettant le travail des personnes autorisées.

J'ai mis en place une zone d'administration protégée par .htpasswd, avec un compte utilisateur admin en base de données. L'accès aux routes d'administration passe par AdminController.php, séparé des routes publiques dans le routeur central (index.php). Les visiteurs publics n'ont accès qu'aux routes déclarées explicitement.


1.4 ✅ Vérifier les conditions de la continuité d'un service

S'assurer qu'un service peut rester disponible ou être rapidement rétabli en cas d'incident, de panne ou d'intervention technique.

Après chaque déploiement SFTP, j'ai vérifié que le site restait opérationnel en testant l'ensemble des routes principales en environnement réel. J'ai également résolu un incident de configuration : le remotePath SFTP incorrect a été diagnostiqué via la console SSH d'Infomaniak, ce qui m'a permis de rétablir une connexion stable entre l'environnement local et le serveur de production.


1.5 ❌ Gérer des sauvegardes

Mettre en place une stratégie de sauvegarde des données et des configurations, avec une procédure permettant de les restaurer en cas de perte ou de corruption.

Non mobilisée dans cette réalisation. Aucune procédure de sauvegarde formalisée n'a été mise en place.


1.6 ✅ Vérifier le respect des règles d'utilisation

Contrôler que l'usage des outils et des systèmes est conforme aux règles définies : chartes, politiques de sécurité, obligations légales (RGPD, licences, etc.).

Les mentions légales du site précisent la licence du contenu (propriété intellectuelle), l'absence de cookies de tracking et les droits de reproduction. J'ai appliqué le principe de Kerckhoffs : les principes d'architecture sont publics et documentés sur le site, les détails d'implémentation sensibles (credentials, chemins exacts) restent privés.

2.1 ❌ Collecter, suivre et orienter des demandes

Recueillir les demandes des utilisateurs, les qualifier, les prioriser et les orienter vers la bonne ressource ou procédure de traitement.

Non mobilisée dans cette réalisation. praxis-debug.net est un projet personnel — il n'y a pas de flux de demandes utilisateurs à gérer.


2.2 ✅ Traiter des demandes concernant les services réseau et système

Diagnostiquer et résoudre des incidents ou des demandes liés à l'infrastructure : réseau, système d'exploitation, serveurs, équipements physiques.

J'ai diagnostiqué et résolu plusieurs incidents d'infrastructure : erreur de remotePath SFTP (Secure File Transfer Protocol), exploration SSH (Secure Shell) pour identifier la structure réelle du serveur Infomaniak, configuration Apache via .htaccess pour le routage et la protection des dossiers sensibles.


2.3 ✅ Traiter des demandes concernant les applications

Diagnostiquer et résoudre des incidents ou des demandes liés aux applications : dysfonctionnement, anomalie, évolution fonctionnelle.

J'ai identifié et résolu des problèmes applicatifs concrets : erreurs de chemins dans les require_once, gestion des routes inexistantes avec code HTTP 404, organisation des vues par sous-dossiers pour éviter les conflits de nommage. Chaque incident a été diagnostiqué, résolu et documenté.

3.1 ✅ Participer à la valorisation de l'image de l'organisation

Contribuer à construire ou améliorer l'image de l'organisation sur le web, en tenant compte de son identité, de sa charte graphique et du cadre juridique applicable.

Le site porte une identité éditoriale cohérente : fil conducteur Conway/méta-cognition, charte graphique unifiée (couleur --teal-fonce, Bootstrap), ton assumé. Les mentions légales sont présentes et conformes à la législation française. Le contenu reflète une posture professionnelle construite — pas un portfolio générique.


3.2 ✅ Référencer les services en ligne

Mettre en œuvre des techniques de référencement (SEO, sitemap, structuration des URL) pour améliorer la visibilité des services en ligne dans les moteurs de recherche.

J'ai configuré robots.txt, choisi un nom de domaine professionnel (praxis-debug.net), mis en place les mentions légales obligatoires. Le site est accessible publiquement avec une URL stable hébergée chez Infomaniak. Le portfolio est référencé dans le tableau de synthèse E5 et consultable par le jury.


3.3 ✅ Participer à l'évolution d'un site Web

Concevoir, modifier ou enrichir un site web en intégrant les données propres à l'organisation, dans le respect de ses besoins et contraintes techniques.

Le site est en développement actif depuis mars 2026 : ajout de contrôleurs, création de vues par matière, enrichissement des pages portfolio. La documentation de suivi trace cette évolution étape par étape. Au 16 mai 2026, le dossier portfolio compte 15 vues, contre 8 prévues initialement dans l'arborescence de départ.

4.1 ✅ Analyser les objectifs et les modalités d'organisation d'un projet

Lire et comprendre un cahier des charges, identifier les contraintes, les acteurs et les ressources nécessaires avant de démarrer une réalisation.

Avant de coder, j'ai formalisé les objectifs (portfolio jury BTS + recruteurs + identité professionnelle), les contraintes (hébergement mutualisé, PHP pur sans framework, délai BTS juin 2026), et les trois audiences cibles. Cette analyse a directement orienté les choix d'architecture — notamment le refus d'un CMS (Content Management System) au profit d'un MVC maison.


4.2 ✅ Planifier les activités

Découper un projet en tâches, les séquencer dans le temps et organiser leur enchaînement pour atteindre les objectifs dans les délais impartis.

Le développement a suivi un ordre défini et priorisé : structure MVC d'abord, vues statiques ensuite, composants dynamiques (veille avec BDD, flux d'articles) reportés en V2. La documentation de suivi a fonctionné comme un journal de bord des étapes validées et des décisions architecturales prises en cours de route.


4.3 ✅ Évaluer les indicateurs de suivi d'un projet et analyser les écarts

Mesurer l'avancement réel d'un projet par rapport à ce qui était prévu, identifier les écarts et les causes de blocage, et ajuster si nécessaire.

J'ai suivi l'avancement par des points réguliers : nombre de contrôleurs fonctionnels, routes opérationnelles, pages portfolio publiées. Les écarts par rapport au plan initial sont identifiés et documentés — par exemple, la table article reste non connectée et le flux de veille est en attente de déploiement dynamique, deux points explicitement reportés en V2.

5.1 ✅ Réaliser les tests d'intégration et d'acceptation d'un service

Vérifier que les composants d'un service fonctionnent correctement ensemble et que le résultat correspond aux attentes exprimées avant mise en production.

Après chaque déploiement SFTP, j'ai testé l'ensemble des routes en environnement réel (production Infomaniak) : cohérence local/serveur, chemins de fichiers, rendu des vues, accès à la zone admin. Ces tests ont permis de détecter et corriger plusieurs erreurs de chemins et de configuration Apache.


5.2 ✅ Déployer un service

Installer, configurer et mettre en production un service dans son environnement réel, de façon opérationnelle et sans interruption du service existant.

Le site est déployé en production sur Infomaniak via SFTP depuis VS Code (extension SFTP avec upload on save). Le déploiement couvre l'application PHP, la base de données MySQL et la configuration serveur Apache. La connexion a été configurée avec le chemin absolu exact identifié via la console SSH.


5.3 ❌ Accompagner les utilisateurs dans la mise en place d'un service

Former, documenter ou guider les utilisateurs pour qu'ils puissent s'approprier un service et l'utiliser en autonomie.

Non mobilisée dans cette réalisation. praxis-debug.net est un site consultatif — il n'y a pas d'utilisateurs à accompagner dans la prise en main d'un service.

6.1 ✅ Mettre en place son environnement d'apprentissage personnel

Structurer les outils, méthodes et ressources qui permettent d'apprendre en faisant, de progresser de façon autonome et de capitaliser ses connaissances.

J'ai structuré un environnement de travail complet : VS Code avec SFTP intégré, environnement local PHP/MySQL, documentation de suivi pour la mémoire de projet, conversations Claude.ai pour la modélisation des concepts avant implémentation. Le choix du MVC maison plutôt qu'un framework était délibérément pédagogique — comprendre avant d'utiliser.


6.2 ✅ Mettre en œuvre des outils et stratégies de veille informationnelle

Identifier des sources fiables, les consulter régulièrement et exploiter les informations recueillies pour rester à jour sur les évolutions technologiques et professionnelles.

La section veille du site documente une démarche structurée : sources identifiées (Cloudflare Blog, Hacker News, IETF/RFC (Request For Comments), ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information)), technologies suivies (eBPF, QUIC/HTTP3, SDN (Software Defined Networking), Zero Trust), fil conducteur thématique sur l'effacement des frontières entre les couches du modèle OSI (Open Systems Interconnection).


6.3 ✅ Gérer son identité professionnelle

Construire et entretenir une présence numérique cohérente avec son parcours et ses compétences : portfolio, profil LinkedIn, livrables publics.

praxis-debug.net est simultanément l'outil et la preuve de cette compétence : nom de domaine professionnel, CV en ligne, portfolio de réalisations, identité éditoriale cohérente et assumée. Le site construit et rend visible une identité professionnelle publique et traçable.


6.4 ✅ Développer son projet professionnel

Analyser ses expériences pour identifier ses points forts, ses axes de progression et les compétences à acquérir en vue d'un objectif professionnel.

Le site documente explicitement ma reconversion, mes choix d'orientation (SLAM avec appétence réseau/système), et les compétences que je veux développer. La page À propos et la page CV articulent un projet professionnel cohérent et réflexif — pas une liste de compétences, mais une trajectoire.

← Retour au portfolio