Vadrouille.kitcreanet.fr— Chronique d’une application web construite pas à pas

Il y a quelques jours, j’ai eu une idée simple mais enthousiasmante : créer une plateforme de découverte de sites web français, inspirée du concept de Cloudhiker. Un bouton, un site au hasard, la surprise au rendez-vous. Cloudhiker est très sympa, mais 99,99% des sites qu’il propose sont des sites américains, rédigés en … américain. Et je me suis dit que créer une version francophone pourrait être sympa comme projet.

Mais derrière cette idée se cachait un défi plus large : montrer qu’il est désormais possible de concevoir une véritable application web même lorsqu’on n’est pas développeur professionnel, à condition d’être bien accompagné, méthodique, curieux et prêt à apprendre en chemin.

Vadrouille est née de cette double ambition : construire un service utile, gratuit et communautaire, tout en expérimentant une nouvelle manière de créer. Non pas seul face à une montagne de code, mais dans une collaboration étroite entre un humain porteur de vision et une intelligence artificielle capable de traduire des besoins en solutions techniques concrètes.

Ce récit raconte donc deux aventures en une : la naissance d’une application web en PHP/MySQL, et la démonstration qu’aujourd’hui, avec les bons outils et la bonne méthode, on peut bâtir un projet ambitieux sans être codeur de formation.

L’idée de départ : simple, mais pas si simple

Tout commence par une contrainte technique claire : hébergement mutualisé O2Switch, PHP 8.x, MySQL. Pas de Node.js, pas de framework exotique, pas de conteneur Docker. Du PHP propre, du SQL maîtrisé, et un code structuré comme si un développeur senior allait le relire demain matin.

L’application s’appelle Vadrouille. Son principe : vous arrivez sur la page d’accueil, vous cliquez sur « Nouvelle vadrouille », et le système vous propulse sur un site web français sélectionné au hasard dans la base de données. Vous pouvez filtrer par catégorie, liker les sites qui vous plaisent, et si vous êtes connecté, soumettre vos propres découvertes.

Derrière ce concept minimaliste, il fallait construire :

• Un système d’authentification complet (inscription, connexion, sessions).
• Un back-office d’administration.
• Un système de modération des sites soumis.
• Une gestion des rôles (utilisateur, modérateur, administrateur).
• Une sécurité solide contre les injections SQL, les failles XSS et les attaques CSRF.

Le chantier était lancé.

Une application construite en dialogue avec l’IA

Ce projet raconte aussi autre chose qu’une aventure de développement web : il montre qu’aujourd’hui, un créateur qui n’est pas programmeur professionnel peut tout de même construire une vraie application, à condition d’avoir une vision claire, de la curiosité et une bonne méthode de dialogue avec une intelligence artificielle.

Dans mon cas, je n’ai pas simplement cliqué sur un générateur. J’ai travaillé pas à pas, en décrivant mes besoins, en posant des questions, en demandant des corrections, en testant chaque fonctionnalité sur le serveur, puis en revenant avec des retours concrets. L’IA n’a pas remplacé ma réflexion : elle a transformé mes intentions en solutions techniques exploitables.

C’est sans doute l’un des enseignements les plus intéressants de cette aventure. On imagine souvent qu’il faut être développeur confirmé pour lancer une application web. En réalité, de nos jours et avec l’apparition de tels outils, il devient possible de créer sans savoir tout coder soi-même, à condition de savoir piloter un projet, observer les erreurs, formuler les bons problèmes et avancer avec rigueur.

Cette collaboration a pris plusieurs formes : rédaction de code PHP, structuration SQL, corrections de bugs, amélioration du design, optimisation des performances et relecture logique du projet. À chaque étape, mon rôle était de donner la direction, de tester dans le réel, de repérer ce qui n’allait pas et de décider de ce qui devait être conservé, corrigé ou simplifié.

Phase 1 : Poser les fondations – La page d’accueil, le cœur du réacteur

La première grande pièce du puzzle, c’est index.php, la page d’accueil que voit chaque visiteur. Elle devait accomplir plusieurs choses en même temps : tirer un site au hasard dans la base, incrémenter son compteur de vues une seule fois par session, afficher les informations de manière élégante, et proposer les boutons d’interaction.

La requête qui tire un site au hasard utilise une méthode optimisée basée sur les IDs des sites, plutôt qu’un tri aléatoire complet de la base de données. Cette approche est particulièrement adaptée à un hébergement mutualisé comme O2Switch, où les performances comptent.

Principe du tirage optimisé : D’abord, la requête calcule les bornes des IDs disponibles (MIN et MAX) parmi les sites valides et filtrés par catégories ou exclusions. Ensuite, elle tire un ID aléatoire dans cette plage, puis récupère le premier site correspondant. Si aucun site n’existe à cet ID (trous dus à des suppressions), un fallback cherche en sens inverse depuis cet ID.

Cette technique s’appuie sur l’index primaire MySQL sur ID, ce qui rend les requêtes très rapides. Plus légère en ressources, idéale pour les environnements mutualisés, elle gère bien les filtres catégories via IN, exclusions sans alourdir. Seul bémol mineur : trous d’IDs, corrigés par fallback sans boucle infinie

Le design : une fiche pure. Visuellement, la fiche site affiche la catégorie en petit texte coloré en haut, le titre en grand, la description, l’URL en gris discret, puis les statistiques vues et likes. Le bouton « Visiter ce site » est rentré dans la carte pour un rendu plus cohérent. Le bouton « Nouvelle vadrouille » est placé plus bas, avec la couleur primaire plus logique dans le flux de lecture.

Phase 2 : Le back-office prend forme

Le dashboard administrateur affiche :

1. Les statistiques globales (nombre de sites en ligne, sites en attente, nombre d’utilisateurs, nombre de catégories).
2. le module de gestion des utilisateurs ;
3. Le module de gestion des sites en attente de modération ;
4. le module de gestion des catégories ;
5. le module de gestion des sites..

La gestion des catégories (admin/categories.php) permet de créer, renommer et supprimer des catégories. La suppression est protégée : impossible de supprimer une catégorie qui contient encore des sites. Une vérification SQL préalable empêche toute erreur.

La gestion des sites (admin/sites.php) liste tous les sites avec leur statut, leur nombre de vues et de likes. Chaque ligne propose des actions : modifier, valider, rejeter, supprimer. Le tableau est responsive avec un scroll horizontal sur mobile.

La gestion des utilisateurs (admin/users.php) est arrivée en cours de route, pour répondre à un besoin évident : un administrateur doit pouvoir voir qui s’inscrit, changer les rôles, et si nécessaire supprimer un compte. La page intègre une barre de recherche par pseudo ou email, un badge coloré par rôle, et un select inline pour changer le rôle directement dans le tableau sans page intermédiaire.

Une protection importante : impossible de modifier ou supprimer son propre compte. Le code compare systématiquement l’ID de la cible avec celui de la session connectée (ne rigolez pas ça arrive plus vite qu’on le le croit – croyez en mon expérience, j’ai vu ça sur un ERP en entreprise qui a vu le compte administrateur supprimé par … l’administrateur .. oui oui c’est possible).

Phase 3 : Le système de rôles

Trois niveaux, trois responsabilités : Au départ, l’application ne distinguait que deux états : connecté ou non. Puis est venue la nécessité d’un rôle modérateur – quelqu’un qui peut valider des sites et gérer le contenu, sans avoir accès à la gestion des utilisateurs ou des catégories.

Trois rôles ont été définis :

Rôle	Permissions
User	Liker, soumettre des sites, gérer son profil
Modérateur	Valider/rejeter des sites, modifier des sites
Admin	Supprimer des sites, gérer les utilisateurs et les catégories

La logique est inclusive : les modérateurs ont accès à tout ce que les users ont, plus la modération ; les admins ont accès à tout.

Le header adaptatif : Le bouton « Administration » dans la navigation apparaît pour les modérateurs ET les admins, mais reste invisible pour les utilisateurs ordinaires.

Phase 4 : La chasse aux bugs

C’est souvent la phase la plus instructive. Pourtant je ne vais pas vous abreuver de descriptifs techniques indigestes mais je vais vous expliquer commet l’IA m’a aidé à corriger les bugs les plus « complexes ».

J’ai été confronté plusieurs fois à de terribles « ERROR 500 ».

Une erreur 500 (Internal Server Error) sur un serveur PHP/MySQL est une réponse générique indiquant que le serveur a rencontré un problème inattendu et n’a pas pu traiter la requête. Et les causes qui provoquent cette erreur sont nombreuses :

• erreur de syntaxe php ;
• problème de permission ;
• limite de mémoire ou temps d’exécution ;
• erreur SQL ;
• fichier .htaccess mal configuré ;
• module php manquant ;
• conflit de version ;
• problème de cache ;
• etc.

Ce qui est épineux pour un développeur aguerri peut rapidement devenir un enfer pour un non-développeur comme moi.

Ici, j’ai utilisé une arme secrète (qui est redoutable quel que soit le prompt que vous utilisez pour faire travailler une IA). Je lui ai demandé de m’aider à débogguer « pas à pas ».

La méthode de débogage : isoler pour identifier. Face aux erreurs 500 :

• Mon compagnon IA m’a d’abord demandé d’activer display_errors temporairement pour avoir un retour clair des erreurs rencontrées par le serveur.
• Ensuite, nous avons remplacé le code suspect par un test minimal en incluant les dépendances une par une.
• Ce texte devait afficher un message après chaque étape pour localiser exactement où ça plante.

Cette approche « diviser pour régner » est universellement applicable. Elle évite de chercher à l’aveugle dans des centaines de lignes de code.

Ce que ce projet m’a enseigné

Au-delà du code lui-même, cette aventure illustre plusieurs vérités du développement web :

• La sécurité se pense dès le début. Tokens CSRF partout, échappement XSS systématique, requêtes préparées.
• Les bugs les plus insidieux sont souvent les plus simples : une colonne manquante, un nom qui diffère de deux lettres.
• Une bonne architecture se lit : chaque fichier suit un pattern cohérent (require, vérifs accès, logique métier, HTML).
• Le déploiement, c’est du développement : .htaccess, permissions, structure & dossiers font partie intégrante du développement de l’application.

Il m’a fallu environ 24 heures pour arriver à ce résultat. C’est déjà incroyablement rapide si on garde en tête que je ne maîtrise pas la technique. Mais je sais que je pourrai faire mieux et plus rapidement la prochaine fois : en structurant mieux mon projet en amont.

Et maintenant ?

Vadrouille est en ligne et il tourne ! Les utilisateurs peuvent s’inscrire, soumettre des sites, les liker, et partir à la découverte du web français. Les modérateurs valident les soumissions. Les administrateurs gardent le contrôle sur les catégories et les comptes.

Ce n’est pas une application parfaite – aucune ne l’est. Mais c’est une application honnête : propre dans son code, sécurisée dans ses fondations, et fidèle à son idée de départ. Un bouton. Un site. La surprise.

Il ne vous reste plus qu’à partir en vadrouille ! https://vadrouille.kitcreanet.fr

Vous pouvez contribuer à enrichir la base avec vos sites pépites préférés ! La seule règle, le site doit être intéressant, amusant, utile ou insolite, pour peu qu’il soit francophone !

Et n’hésitez pas non plus à le partager sur vos réseau sociaux ! C’est un site qui se veut communautaire !

Allez, c’est tout pour cette fois ! À bientôt !

Et restez curieux !