SlapIA (Web)

Code source de la partie web de SlapIA, publié dans un objectif de transparence et pour faciliter la contribution open-source.

TL;DR : vous êtes ici pour lire le code, l’améliorer, le critiquer poliment (ou moins poliment, mais avec des PR). Nous, on veut que ce soit simple à comprendre et simple à faire évoluer.

---

Sommaire

• Pourquoi ce repo existe
• Ce que vous trouverez ici
• Stack & prérequis
• Démarrage rapide
• Structure du projet
• Sitemap
• Sécurité
• Contribuer
• Licence
• Contact

---

Pourquoi ce repo existe

SlapIA est utilisé “dans la vraie vie”, donc autant rendre le code auditable, améliorable et discutable.

Objectifs :

• Transparence : expliquer comment ça tourne, ce qui est fait côté web, et où sont les limites.
• Communauté : permettre aux gens de proposer des améliorations (perf, sécurité, UX, docs…).
• Qualité : plus d’yeux = plus de chances de repérer les bugs avant qu’ils ne se transforment en légende urbaine.

---

Ce que vous trouverez ici

• Le site web (PHP) et ses pages.
• Une couche API (dossier api/).
• Des assets (CSS/JS/visuels) et des includes partagés.
• Une génération/gestion de sitemap (utile pour le SEO, et pour calmer Google).

Note : ce repo est publié pour contribuer à l’écosystème. Certaines parties “sensibles” (secrets, clés, configuration infra, etc.) ne doivent pas être dans Git. C’est normal. (Et sain.)

---

Stack & prérequis

• PHP (recommandé : version moderne 8.x, compatible 7.4+ selon votre environnement)
• Un serveur web type Apache (avec .htaccess) ou Nginx (avec règles de réécriture équivalentes)
• Optionnel : un environnement local type Docker / MAMP / WAMP / Laravel Valet, etc.

Langages principaux du repo : PHP / CSS / JavaScript.

---

Démarrage rapide

1) Récupérer le code

git clone https://github.com/SlapIA-com/SlapIA.git
cd SlapIA

2) Lancer en local (simple)

Si votre projet ne dépend pas de règles de réécriture complexes, vous pouvez tenter :

php -S 127.0.0.1:8000 -t .

Puis ouvrir http://127.0.0.1:8000

3) Lancer “comme en prod” (recommandé)

• Configurez un VirtualHost / ServerBlock
• Pointez le DocumentRoot vers la racine du repo
• Assurez-vous que PHP est bien activé
• Si vous êtes sur Apache : autorisez l’usage de .htaccess (AllowOverride)

---

Structure du projet

Le but : que vous puissiez trouver les choses sans faire un safari de 3 heures.

• index.php : point d’entrée
• pages/ : pages / vues
• includes/ : includes partagés (helpers, config, templates, etc.)
• api/ : endpoints / logique API
• assets/ : CSS/JS/images
• .htaccess : règles Apache (rewrite, headers, etc.)
• sitemap.php / sitemap.xml : sitemap (auto ou statique selon le cas)

---

Sitemap

• sitemap.xml : sitemap consommable par les moteurs
• sitemap.php : génération/maintenance (selon la stratégie retenue)

Si vous modifiez des routes/pages, pensez à vérifier que le sitemap reste cohérent.

---

Sécurité

Quelques règles simples (les classiques, parce que les classiques marchent) :

• Ne commitez jamais de secrets (clés API, tokens, mots de passe).
• Préférez des variables d’environnement ou un fichier de config non versionné.
• Si vous découvrez une vulnérabilité, merci d’éviter le “post LinkedIn héroïque” avant de nous prévenir.

---

Contribuer

Les contributions sont bienvenues. Vraiment.

Workflow recommandé

1. Ouvrir une Issue (bug / idée / question)
2. Fork + branche (feat/... ou fix/...)
3. PR claire, petite, testable

Bonnes pratiques

• PR petites > PR mammouths
• Décrire le pourquoi (pas seulement le quoi)
• Éviter d’ajouter des dépendances “juste pour éviter 15 lignes de code”

---

Licence

⚠️ À préciser : ajoutez un fichier LICENSE à la racine (MIT / Apache-2.0 / GPL / …) pour clarifier les droits d’utilisation.

Sans licence explicite, c’est juridiquement flou… et l’open-source aime moyennement le flou.

---

Contact

• Issues GitHub : pour bugs / demandes / idées
• PR : pour les améliorations concrètes

Merci de contribuer, d’auditer, d’optimiser, et globalement d’aider à rendre le web un peu moins fragile qu’un château de cartes sous ventilateur.