Un moteur web conçu
comme un système d'exploitation

BeamReactor n'est pas un assemblage de scripts. C'est un système construit autour d'un noyau centralisé — le moteur XDP — inspiré de la structure interne d'un système d'exploitation.

Chaque requête HTTP entre par un point unique. Le noyau gère le routage, l'application des protocoles de sécurité, la gestion de session, le chargement des plugins et le rendu de sortie. Aucun script PHP ne peut s'exécuter sans passer par lui. Ce n'est pas une convention — c'est une impossibilité structurelle imposée par l'architecture elle-même.

Cette centralisation garantit l'application uniforme des protocoles de sécurité sur l'ensemble du système, de l'authentification utilisateur au rendu final de la page. Les plugins ne peuvent pas contourner la sanitization, ne peuvent pas émettre de SQL brut, et ne peuvent pas interrompre l'exécution (exit / die sont structurellement interdits). Le noyau conserve toujours le contrôle pour assurer la fermeture propre de la session et la gestion cohérente des erreurs.

Chaque fonctionnalité de BeamReactor vit en tant que plugin autonome. Le noyau route, sécurise et orchestre — rien de plus. Cela signifie que la surface d'attaque d'une installation donnée est exactement proportionnelle à ce que vous activez. Un plugin inactif représente zéro ligne de code exposé.

Quand un plugin est appelé, le moteur prend en charge automatiquement le chargement de la configuration, l'injection des bibliothèques, la sélection de la locale selon la langue de l'utilisateur, et l'enregistrement des routes. Plusieurs plugins coexistent sur la même page sans collision — chacun opère dans son propre espace de noms avec ses propres ressources CSS et JavaScript.

Chaque plugin embarque sa propre documentation (/doc/), sa propre suite de tests (/tests/), sa propre cartographie de modération pour la conformité RGPD (.moderation.json), et sa propre déclaration de sitemap (.sitemap.json) pour le moteur de recherche. L'installation est un dépôt de dossier. La suppression est un retrait de dossier.

La sécurité dans BeamReactor n'est pas une couche ajoutée par-dessus. C'est l'architecture elle-même. Chaque donnée entrant ou sortant du système passe par Sanitizer\Parser, qui valide contre des types stricts : primitifs (bool, int, float, string avec contraintes de longueur), structurés (email, URL, UUID, IP, date, JSON), riches (HTML avec whitelist de balises, Markdown, SQL en requêtes préparées uniquement), et métier (fichiers avec validation MIME/taille/extension, images, tokens).

Les interactions avec la base de données utilisent exclusivement des requêtes préparées. La concaténation directe de paramètres est structurellement impossible via la couche d'abstraction SQL (BDAL). Le système détecte et prévient les injections SQL, le XSS, les attaques par overflow de chaînes, les injections de commandes shell, le path traversal et les manipulations NaN/Infinity.

Les sessions sont protégées par le tracking permanent de l'IP, l'empreinte User-Agent, la limitation adaptative du débit de requêtes, et l'expiration temporelle. L'authentification utilise Argon2id côté serveur et PBKDF2 côté client avec salage individuel par utilisateur, 2FA, et jetons anti-CSRF à usage unique. Des honeypots actifs — champs de formulaire cachés, URLs pièges, analyse de temporisation des requêtes — identifient et mettent en quarantaine les attaquants avant qu'ils n'atteignent vos données.

BeamReactor gère les niveaux de privilèges de manière dynamique. Les valeurs par défaut sont définies dans la configuration, mais peuvent être surchargées au runtime depuis la base de données ou depuis un include — en fonction de la charge serveur, du niveau de menace, ou de la performance des plugins.

Sous charge élevée, les plugins gourmands en ressources sont automatiquement restreints aux utilisateurs de niveau supérieur. En cas d'attaque, le système peut verrouiller l'accès aux seuls administrateurs sans redéploiement. Un plugin qui dépasse une seconde de temps de génération est automatiquement mis en quarantaine — désactivé pour les utilisateurs normaux tandis que les administrateurs conservent l'accès pour le diagnostic.

C'est du load balancing au niveau applicatif basé sur la hiérarchie de privilèges. Le système mesure le temps de génération par plugin, évalue la charge actuelle contre le nombre de connexions et la capacité, décide de restreindre ou non l'accès, et préserve l'accès admin pour le diagnostic. Aucune intervention humaine requise. Un plugin buggé ou attaqué ne fait pas tomber le site — il s'isole de lui-même.

BeamReactor repose sur un principe simple : les données de vos utilisateurs leur appartiennent. Collecte minimale, données sensibles chiffrées, aucun tracking tiers, suppression réelle (pas un simple flag), et export complet des données. Ces principes étaient en place depuis 2003 — douze ans avant la rédaction du RGPD.

Chaque plugin inclut un fichier .moderation.json qui cartographie exactement quelles données utilisateur il stocke et comment ces données doivent être traitées lors d'une anonymisation, d'un effacement, ou du traitement d'une plainte. Quand une demande RGPD est formulée, le moteur parcourt la cartographie de modération de chaque plugin installé et exécute l'action appropriée — anonymiser, supprimer ou exporter — sans intervention manuelle par plugin.

De même, chaque plugin déclare un .sitemap.json qui cartographie son contenu public pour le moteur de recherche interne et le générateur de sitemap. Cela garantit que l'indexation du contenu est toujours exacte, toujours à jour, et toujours sous le contrôle de l'auteur du plugin plutôt que d'un crawler global fragile.

Même les formats de documents sont conçus pour la performance. Les formats .dta et .err sont zero-parse, zero-BDD, zero-fonction au runtime : une directive par ligne, clé-valeur séparée par un espace, chargés une seule fois au bootstrap en constantes PHP pures mises en cache par opcache. Le parsing prend moins de 0.01µs. Une page d'erreur complète pèse moins de 2 Ko.

L'éditeur WYSIWYG, le système multilingue, le moteur d'analytics, le catalogue de bots — aucun de ces composants ne dépend de services externes. Pas de Google Analytics, pas de dépendance CDN, pas de scripts externes qui communiquent avec l'extérieur. Tout tourne sur votre serveur, sous votre contrôle.

BeamReactor a été conçu, développé et maintenu par le même architecte depuis 2003. Il n'y a eu aucun transfert, aucune réécriture, aucune décision de comité. Chaque ligne de code suit la même philosophie security-first, performance-first posée dès le premier jour.

Le résultat est une cohérence architecturale qu'aucun CMS communautaire ne peut égaler. Le code est 100% auditable. Le bilan sécurité est public : zéro CVE connue en 22 ans. Le système fonctionne avec zéro dépendance tierce — pas de Composer, pas de Node, pas d'étape de build. Upload FTP, configuration, exécution.

Les CMS populaires sont des cibles massives. Une vulnérabilité découverte dans WordPress affecte des millions de sites simultanément. L'architecture unique de BeamReactor et sa base d'installation confidentielle le rendent structurellement inintéressant pour les attaquants automatisés — une sécurité par originalité architecturale, en complément d'une vraie sécurité technique.