EEG ERP — Exploit Engineering Group

ERP web et PWA terrain d'Exploit Engineering Group. L'application réunit CRM, devis et factures, projets, interventions, GMAO, inspections réglementaires, achats, documents, QHSE, notifications et administration multi-entreprises dans un même parcours opérationnel.

Production : exploit-engineering.nordikperform.chatgpt.site

Dépôt : synaval/EEG_ERP

Architecture

• Next.js 16, React 19 et TypeScript, compilés par Vinext/Vite pour Cloudflare Workers.
• Cloudflare D1 avec Drizzle ORM pour les données métier et les migrations.
• Cloudflare R2 pour les fichiers, preuves, rapports et logos.
• Authentification Sign in with ChatGPT injectée par Sites.
• Contrôle d'accès multi-tenant par entreprise, rôle et permission.
• PWA installable avec cache hors ligne, file locale bornée d'opérations, synchronisation différée et reçus d'idempotence persistés pour éviter les doubles écritures lors d'une reprise réseau.
• GitHub Actions comme contrôle obligatoire avant intégration sur main.

Les routes privées sont sous app/api/erp. Les routes app/api/public et les liens par jeton sont volontairement publics et limités à la ressource désignée. L'ingestion IoT utilise un jeton d'appareil haché. Les secrets fournisseur ne doivent jamais être placés dans le dépôt.

Prérequis

• Node.js >=22.13.0
• npm avec le package-lock.json du dépôt
• Sous Windows : Git Bash ou WSL pour les scripts npm basés sur Bash
• Sous Linux/CI : bash, curl, flock et GNU timeout

Installation et développement

npm ci
npm run dev

L'interface est alors servie par Vite/Vinext. Les ressources locales D1 et R2 sont simulées conformément à .openai/hosting.json et vite.config.ts.

Commandes de contrôle :

npm test
npm run lint
npm run audit:production
npm run validate:artifact
npm run db:generate

npm test effectue d'abord une construction vérifiée puis exécute les tests Node : rendu PWA, sécurité et exécution des routes, codes agents, file hors ligne, service worker et cohérence des migrations. La CI exécute cette commande sur chaque pull request et chaque push vers main.

Configuration d'exécution

Copier .env.example uniquement pour un environnement local. Dans Sites, déclarer les variables dans la configuration sécurisée du projet, jamais dans Git.

Variable	Obligatoire	Usage
OPENAI_API_KEY	Non	Assistant IA ERP
OPENAI_MODEL	Non	Modèle IA, valeur par défaut documentée dans .env.example
WAVE_API_KEY	Non	Paiement Wave
WAVE_SIGNING_SECRET	Non	Vérification des callbacks Wave
FLW_SECRET_KEY	Non	Paiement Flutterwave

Sans ces secrets, le cœur ERP reste opérationnel. Les routes IA ou paiement concernées répondent explicitement 503 setupRequired au lieu de simuler un succès.

Base de données et migrations

Le schéma applicatif est dans db/schema.ts. Les migrations ordonnées sont dans drizzle/ et leur journal dans drizzle/meta/_journal.json.

Règles :

1. Modifier db/schema.ts.
2. Générer une migration avec npm run db:generate.
3. Relire le SQL ; ne jamais modifier une migration déjà appliquée.
4. Exécuter npm test, qui vérifie que chaque entrée du journal possède exactement un fichier SQL.
5. Déployer la nouvelle version par Sites afin que l'historique reste associé au commit publié.

Avant une migration destructive, exporter D1 et sauvegarder les objets R2 concernés. Une restauration doit utiliser l'export D1 et la version R2 pris ensemble au même instant logique.

Publication et alignement

Les trois références suivantes doivent toujours désigner le même commit :

1. main sur GitHub ;
2. le dépôt local canonique C:\Users\HP\Downloads\Cabinet Nordik\3. Technologie\Exploit Suit™ ;
3. la source puis la version déployée du projet Sites appgprj_6a5bb71a4da08191ac1ea8d999e0324d.

Procédure de publication :

1. Créer une branche, exécuter npm test, pousser et ouvrir une pull request.
2. Attendre la réussite de GitHub Actions puis fusionner sans force-push.
3. Mettre le dépôt canonique à jour avec git pull --ff-only origin main.
4. Pousser exactement le SHA de main vers la source Sites.
5. Construire et enregistrer une version Sites, la déployer, puis attendre l'état success.
6. Comparer les trois SHA et contrôler les journaux Worker.

Retour arrière et reprise

En cas d'incident applicatif :

1. Suspendre les nouvelles écritures si l'intégrité des données est en doute.
2. Identifier le dernier SHA GitHub et la dernière version Sites sains.
3. Redéployer cette version Sites ; ne pas réécrire l'historique Git.
4. Si une migration est en cause, restaurer l'export D1/R2 correspondant après validation métier.
5. Créer un correctif sur une branche, repasser toute la CI et publier selon la procédure d'alignement.
6. Vérifier /, /erp, les journaux Worker, l'ouverture des devis/factures et un parcours terrain hors ligne avant réouverture.

Sécurité et accès

• Deux comptes explicitement configurés dans app/crm/auth.ts disposent du rôle super-administrateur.
• Les autres utilisateurs doivent avoir une adhésion active à une entreprise et les permissions nécessaires.
• Les invitations sont liées à l'adresse ChatGPT authentifiée, expirent et sont journalisées.
• Les codes agents sont normalisés puis hachés avec PBKDF2-SHA-256 et un sel aléatoire.
• Les routes de données vérifient le périmètre entreprise avant lecture ou écriture.
• La politique d'accès Sites constitue une barrière supplémentaire et doit être élargie volontairement avant un pilote multi-utilisateur.

Validation avant mise en service

• CI verte sur le SHA publié.
• GitHub, dépôt canonique et Sites sur le même SHA.
• Aucun secret dans Git ni dans les journaux.
• Variables IA/paiement configurées uniquement si les fonctions sont activées.
• Politique d'accès Sites et utilisateurs pilotes validés.
• Test métier manuel : client → devis → acceptation → facture → paiement.
• Test terrain manuel : installation PWA → intervention → photo/signature → perte réseau → resynchronisation.
• Sauvegarde D1/R2 et procédure de restauration testées sur un environnement non productif.

Limites opérationnelles explicites

L'activation réelle des paiements, de l'IA et d'un pilote multi-utilisateur dépend respectivement de secrets marchands, d'une clé OpenAI et d'une décision d'accès externe. Ces éléments ne peuvent pas être fabriqués par le code et doivent être fournis ou approuvés par le propriétaire du projet.