Un tutoriel YouTube de 2h30 datant de 2021 pour construire une application de gestion de patients pour cabinets médicaux : prise de rendez-vous, suivi des visites, historique patient. Laravel 8, React, InertiaJS. En 2025, plus rien ne fonctionne tel quel.
Temps passé : une journée complète. Ratio : 1h de tutoriel = 4h de travail réel.
Ce ratio 1:4 pourrait ressembler à un échec. C’est exactement l’inverse : chaque obstacle rencontré a été une opportunité d’apprentissage. Les problèmes de compatibilité m’ont forcé à comprendre les dépendances en profondeur. Les bugs du code original m’ont poussé à explorer l’architecture InertiaJS au-delà du tutoriel.
Un projet qui “ne marche pas” est souvent plus formateur qu’un projet qui fonctionne du premier coup.
Principe 1 : Scanner avant d’agir
Avant de toucher au code, j’ai lancé un audit des dépendances :
docker run --rm -v $(pwd):/app aquasec/trivy fs --scanners vuln,secret /app
30 secondes plus tard, j’avais la cartographie complète :
| Source | Vulnérabilités | Sévérité max |
|---|---|---|
| Laravel 8 | 1 | MEDIUM |
| Axios | 3 | HIGH |
| webpack-dev-server | 2 | MODERATE |
C’est exactement le même réflexe que j’applique sur les projets d’infrastructure en entreprise. Avant de proposer des améliorations, il faut mesurer l’existant. On ne peut pas améliorer ce qu’on n’a pas inventorié.
Dans le cadre de mon approche inventory-driven, ce scan initial est systématique. Que ce soit pour 3 serveurs ou 400 applications, la première étape est toujours la même : établir l’état des lieux.
Principe 2 : Environnement reproductible
Décision : Dockeriser plutôt qu’installer PHP 8.0 en local.
Le tutoriel date de 2021. Installer PHP 8.0 nativement en 2025 sur une machine qui a d’autres projets = conflits garantis, temps perdu, configuration non reproductible.
Docker résout tout ça : isolation complète, reproductibilité garantie, une seule commande pour lancer le projet.
services:
app:
build: .
volumes:
- .:/var/www/html
ports:
- "8000:8000"
C’est le même principe que mes déploiements automatisés en entreprise. Un projet doit pouvoir se déployer avec une seule commande, que ce soit docker compose up ou terraform apply.
Principe 3 : Prioriser avec une grille effort/impact
Voici comment j’ai décidé quoi corriger et quoi ignorer :
| Décision | Effort | Impact | Durée de vie | Verdict |
|---|---|---|---|---|
| Migrer Laravel 8 → 11 | Élevé | Moyen | Nulle | ❌ Skip |
| Fixer Axios (CVE HIGH) | Faible | Élevé | N/A | ✅ Fix |
| Remplacer MySQL par SQLite | Faible | Simplifie | N/A | ✅ Do |
| Corriger les bugs bloquants | Moyen | Critique | N/A | ✅ Do |
| Refactorer le code | Élevé | Faible | Nulle | ❌ Skip |
Le pragmatisme paie. Laravel 8 n’a plus de support sécurité. Mais ce projet ne va jamais en production. Le ratio effort/bénéfice d’une migration serait catastrophique.
Cette grille effort / impact / durée de vie est celle que j’utilise pour prioriser les chantiers d’automatisation en entreprise. Elle évite de perdre du temps sur des optimisations qui n’apportent rien.
Les corrections appliquées
Fix sécurité Axios
Une ligne dans package.json :
{
"overrides": {
"axios": "^1.13.2"
}
}
Résultat : 5 vulnérabilités HIGH → 2 vulnérabilités MODERATE (dev-only). Fix simple, impact élevé, zéro breaking change.
Simplification : MySQL → SQLite
Pour un projet d’apprentissage, MySQL est overkill. SQLite = zéro configuration, un fichier, backup trivial.
DB_CONNECTION=sqlite
DB_DATABASE=/var/www/html/database/database.sqlite
En production, on utiliserait PostgreSQL. Mais ce n’est pas le but ici, et adapter plus tard prendrait 10 minutes.
Corrections minimales du code
Le code original avait des bugs qui empêchaient de tester les flux principaux de l’application (création de patient, enregistrement d’une visite). J’ai corrigé le strict minimum pour débloquer l’apprentissage.
Pas de refactoring cosmétique. L’objectif est de comprendre l’architecture originale, pas de la transformer.
Le temps gagné permet de créer de la valeur
En appliquant mes trois principes, j’ai économisé plusieurs heures de debug et de configuration. Ce temps récupéré, je l’ai investi dans des améliorations UX.
Édition inline des visites passées
Le tutoriel original ne permettait pas de modifier les visites une fois créées — problématique pour un vrai cabinet médical où les informations évoluent. J’ai ajouté l’édition inline, ce qui m’a permis de comprendre en profondeur comment InertiaJS gère les formulaires et la réactivité avec React.
Validation des formulaires côté client
Dans la fiche patient, les champs comme l’âge ou le poids acceptaient n’importe quel texte (on pouvait saisir “abc” au lieu d’un nombre). J’ai ajouté une validation qui vérifie la saisie en temps réel et affiche un message d’erreur clair si le format est incorrect.
Pourquoi c’est important
Sans la méthodologie, j’aurais passé ma journée à debugger des problèmes de versions PHP/Node, chercher pourquoi MySQL ne démarre pas, ou migrer Laravel 8 vers 11 “par principe”.
Au lieu de ça, j’ai pu apprendre ce que je voulais apprendre (InertiaJS) et améliorer le projet au-delà du tutoriel original. C’est exactement le même effet en entreprise : une infrastructure bien outillée libère du temps pour l’innovation.
Ce que ça m’a appris sur la dette technique
Ce tutoriel de 2021 est un cas d’école de dette technique accélérée : dépendances non maintenues (Laravel 8 EOL, Axios vulnérable), documentation absente, environnement implicite (“ça marchait sur ma machine” en 2021).
C’est précisément parce que ça ne marchait pas que j’ai appris. En entreprise, ces mêmes symptômes passent souvent inaperçus jusqu’à l’incident en production. Ici, j’ai pu les observer, les diagnostiquer, et comprendre comment les prévenir.
L’approche inventory-driven que j’applique sur les infrastructures est née de ce type d’expériences :
- Inventaire centralisé des dépendances et versions → pour ne jamais découvrir un EOL en urgence
- Scan automatisé des vulnérabilités → pour anticiper au lieu de subir
- Environnements reproductibles par défaut → pour que “ça marchait sur ma machine” ne soit plus jamais une excuse
Bilan
| Problème rencontré | Ce que j’ai appris |
|---|---|
| Dépendances obsolètes | Maîtrise de Trivy, lecture de CVE |
| Environnement incompatible | Dockerisation d’apps legacy |
| Bugs dans le code | Architecture InertiaJS en profondeur |
| UI incomplète | Gestion des formulaires React/Inertia |
Ce qu’il faut retenir
- Scanner avant d’agir : 30 secondes de Trivy évitent des heures de debug
- Environnement reproductible : Docker n’est pas un luxe, c’est la base
- Priorisation pragmatique : Savoir quand NE PAS migrer est aussi important que savoir le faire
- Les échecs sont des données : Chaque blocage est une opportunité de comprendre en profondeur
Application à grande échelle
Ces trois principes sont les mêmes que j’applique sur des projets de 400+ applications : scan systématique avant intervention (Trivy, SonarQube, SBOM), déploiement automatisé et reproductible (Terraform, Ansible, GitLab CI), priorisation par grille effort/impact/criticité.
La seule différence : l’échelle. La méthodologie reste identique.
Pour industrialiser ce scan à l’échelle d’une organisation, j’ai développé le Carnet de Santé IAC — un outil qui audite automatiquement tous les repos Terraform d’un groupe GitLab et calcule un score de santé pour chaque projet.
Ressources
- Infrastructure as Code Inventory-Driven — L’article détaillé sur mon approche
- Gestion des dépendances : Audit de sécurité — Guide technique complet
Ce retour d’expérience illustre une conviction : les projets qui résistent sont souvent les meilleurs professeurs. La méthodologie DevOps ne sert pas qu’à “faire marcher les choses” — elle transforme chaque obstacle en opportunité d’amélioration.