Le 3 septembre 2026, un candidat local isolé d’OCCASH a été soumis à une campagne de tests automatisés et à un audit de sécurité défensif. Les résultats, le périmètre et les limites sont présentés ensemble.
Campagne défensive · 3 septembre 2026
OCCASH a fait l’objet d’une campagne de tests automatisés et d’un audit de sécurité défensif assisté par les capacités OpenAI Daybreak. Sur le périmètre testé le 3 septembre 2026 : 12 surfaces de sécurité examinées, aucun finding validé et reportable, 617 tests serveur et 1 365 contrôles navigateur réussis.
Daybreak réunit des modèles et des outils de défense, un accès responsable et un écosystème destiné à des défenseurs approuvés. La campagne aide à examiner un dépôt et ses alertes, à valider les vulnérabilités plausibles puis à transformer les constats en corrections revues et vérifiées. Les décisions importantes restent sous responsabilité humaine.
Lire la présentation officielle d’OpenAIAuthentification, permissions, isolation des magasins, entrées et sorties, requêtes SQL, documents, transactions argent-stock, stockage navigateur, coffre propriétaire, sauvegardes, intégrations et confidentialité.
Politique de conservation locale, inventaire des dépendances, configuration effective d’hébergement et revue exhaustive des écritures dynamiques dans l’interface restent à approfondir. Un résultat nul signifie seulement qu’aucun finding reportable n’a été validé dans le périmètre analysé. Les tests devront être rejoués après chaque changement important et avant toute mise en production de l’application.
Limite indispensable : ces résultats sont limités à la version et au périmètre testés. Ils ne constituent ni une certification d’OpenAI, ni une garantie d’absence de vulnérabilité.
La sécurité n’est pas présentée comme une promesse vague : elle repose sur des séparations et des contrôles visibles dans l’architecture actuelle.
Chaque société cliente possède son organisation racine. Le modèle standard est une plateforme multi-organisations cloisonnée ; une instance physiquement dédiée reste possible selon le contrat.
Clients, salariés, badges, postes, caisses, stock, documents, comptes fournisseurs et livre de police sont rattachés au magasin imposé par le serveur.
Le salarié actif, son niveau et ses certifications sont contrôlés côté interface et côté API avant les opérations protégées.
Contrats, pièces, PDF fournisseurs, photos et documents RH sont chiffrés avec une clé serveur privée et ne disposent d’aucun chemin public direct.
Les opérations centrales importantes ajoutent une nouvelle trace au lieu d’effacer silencieusement l’événement précédent.
Une sauvegarde chiffrée a été restaurée dans une base temporaire puis comparée à la source. La supervision publiée suit base, sauvegardes, courriels et tâches sans enregistrer de donnée client.
Tablette de signature et téléphones d’inventaire utilisent des codes courts à usage unique, valables cinq heures, révocables et conservés uniquement sous forme de HMAC.
L’empreinte, la version du contrat et la signature sont vérifiées ensemble afin qu’une modification du document impose une nouvelle lecture et une nouvelle signature.
L’objectif est de comprendre une opération sans exposer plus de données que nécessaire.
Le badge, le niveau d’accréditation et le magasin sont associés aux actions protégées.
Achat, vente, retour, dossier SAV, document, réglage ou décision restent identifiables.
Le contexte serveur identifie par exemple « Caisse Vente 1 » sans dépendre d’un nom librement envoyé par le navigateur.
Les versions et horodatages aident à refuser une modification devenue périmée.
Les avancées ci-dessous ont franchi les contrôles locaux automatisés. Leur état reste distinct d’une publication de bêta ou d’une validation terrain.
Propositions vendeur, prix, dates et historique utile sont filtrés côté serveur par client et par magasin, sans inventer le motif d’une vente non conclue.
Les états du contrat, la propriété du produit, le litige et le règlement unique du déposant sont couverts. La correction d’une vente déjà réalisée reste à terminer.
Chiffrement, verrouillage, récupération et frontières de rôles ont été testés avec des données synthétiques. Le coffre technique reste désactivé par défaut.
Les restaurations complètes et sélectives réussissent sur base jetable. Le disque plein, l’archive interrompue, la copie hors site et les objectifs de reprise restent à éprouver.
Statut : validé localement par les suites automatisées ; recette manuelle d’Allan encore requise ; publication de la bêta bloquée tant que sa cible distante n’est pas exclusive.
OCCASH distingue volontairement les mécanismes déjà raccordés des validations qui exigent encore des preuves externes et des essais réels.
Suites serveur et navigateur, frontières de rôles, coffre désactivé par défaut et restaurations sur données synthétiques.
Validation d’Allan, impression, périphériques, concurrence physique et journée multi-postes.
Juridique, RGPD, comptabilité, fiscalité, dépendances et configuration distante effective.
Position actuelle : la bêta est réservée aux données fictives. Aucun client réel, IMEI réel ou identifiant bancaire réel ne doit y être enregistré.
Consultez l’avancement réel et les blocages encore suivis avant la production.
