Qavirio Logiciels · Systèmes · Solutions numériques
TECHNICAL REFERENCE

Architecture & ingénierie

Réponses techniques pour DSI, RSSI, IT, procurement et reviewers techniques. Nous publions assez pour évaluer architecture, discipline d’ingénierie et limites de sécurité — sans publier identifiants, endpoints internes, schémas de données ou détails de durcissement qui faciliteraient un abus.

Stacks technologiques

Web applications

Python · Django · PostgreSQL · HTML/CSS · JavaScript

Logique métier server-side, données relationnelles, workflows par rôles et déploiements hébergés.

Qavirio NERVE

C# · .NET · WPF · SQLite

Produit desktop Windows x64 avec stockage local des preuves et limites de sources actuelles en lecture seule.

Qavirio QCE

Python · local-first services · local model routes

Stack R&D pour workflows cognitifs locaux, intelligence web contrôlée et surveillance défensive.

Web & Digital

PHP · WordPress · WooCommerce · JavaScript

Sites professionnels, commerce, contenu et outils web lorsqu’une architecture CMS est pertinente.

Principes d’architecture

Modulaire avant distribué

Des frontières de domaine et de module claires priment sur les microservices pour les microservices. La distribution vient seulement d’exigences réelles de scale, intégration ou isolation.

Autorisation server-side

La visibilité UI n’est pas une frontière de sécurité. Les accès sensibles sont appliqués dans la logique applicative, les requêtes et les services.

Least privilege

Rôle, tenant, affectation, contexte et nécessité opérationnelle déterminent l’accès. Le titre de fonction seul ne suffit pas.

Fail closed

Secrets manquants, configuration de déploiement invalide ou autorisation ambiguë conduisent lorsque pertinent à un blocage plutôt qu’à une poursuite silencieuse.

Séparation des environnements

Développement, démo contrôlée et production utilisent des secrets, comptes, jeux de données et profils de déploiement séparés.

Preuves avant suppositions

Les claims de release suivent des tests pertinents et une validation runtime cible. Un contrôle statique n’est pas présenté comme une acceptation production.

Cycle de développement sécurisé
  • Définir périmètre, catégories de données, rôles et scénarios négatifs d’autorisation.
  • Utiliser threat- et misuse-thinking pour les workflows sensibles.
  • Revue code/dépendances, scan secrets et intégrité package avant release.
  • Valider migrations, tests de régression, tests sécurité et matrices de rôles ensemble.
  • Arrêt sûr / rollback lorsqu’une gate d’acceptance échoue.
  • Conserver les preuves de release : hashes, rapports, logs pertinents et résultats de tests.
Tests & acceptance
  • Tests unitaires et métier lorsque les règles le justifient.
  • Flows d’intégration et HTTP incluant authentification, CSRF et sessions.
  • Matrice d’autorisation positive et négative par rôle.
  • Drift migrations, schéma et continuité des données.
  • Sanity checks navigateur/responsive pour workflows critiques.
  • Readiness runtime cible avant qu’une release hosted/enterprise soit déclarée live.
Déploiement & opérations

Edge HTTPS

Les déploiements web publics terminent TLS sur un edge/reverse proxy contrôlé. Les services application et base ne sont pas exposés directement sans nécessité.

Secrets & configuration

Les secrets restent hors source et packages ; la configuration production est injectée et contrôlée par environnement.

Sauvegarde & restauration

Sauvegarde, rétention, tests de restauration et responsabilités sont définis par déploiement.

Monitoring & incidents

Health, événements sécurité pertinents et erreurs opérationnelles doivent être détectables sans surveillance personnelle inutile.

Données, privacy & journalisation
  • La minimisation commence par la finalité et la nécessité professionnelle, pas par ce qui peut techniquement être stocké.
  • Les snapshots historiques peuvent rester immuables lorsque preuve, audit ou traçabilité financière l’exigent.
  • Les logs doivent permettre sécurité et support sans dupliquer par défaut des contenus sensibles.
  • AIPD/DPIA, durées de conservation, sous-traitants et lieu d’hébergement sont évalués par déploiement réel.
Dépendances & chaîne logicielle
  • Les dépendances sont limitées au besoin fonctionnel et inventoriées lors des releases.
  • SBOM/preuves de dépendances sont fournies lorsque le produit ou procurement l’exige.
  • Les packages de release reçoivent des hashes d’intégrité et sont contrôlés pour secrets/credentials locaux inattendus.
  • La réponse aux vulnérabilités et la politique de mise à jour sont définies par baseline produit et modèle de distribution.
FAQ technique
Qavirio utilise-t-il une stack unique ?

Non. La stack suit le type de produit, le déploiement, la maintenabilité et les exigences de sécurité.

Qavirio utilise-t-il une IA externe ?

Pas comme défaut générique. NERVE 1.0 Final n’a aucun fournisseur IA externe configuré. QCE est une R&D local-first. D’autres produits ne peuvent utiliser que des services externes explicitement conçus et déclarés.

NERVE peut-il modifier les systèmes sources ?

Les connecteurs NERVE 1.0 Final actuels sont en lecture seule et la baseline ne contient pas d’action executor actif.

Où Accueil Enfance est-il hébergé ?

La démo et chaque déploiement client réel sont des environnements séparés. Région, sous-traitants, sauvegarde, rétention et SLA sont définis pour la mission réelle.

Êtes-vous certifiés ISO 27001 ?

Pas encore. ISO/IEC 27001 est le premier objectif formel de certification. Aucun claim avant délivrance indépendante.

Pouvez-vous fournir un document sécurité ou un diagramme d’architecture ?

Oui, pour une évaluation concrète. Le public voit le niveau système ; les dataflows, détails réseau et controls spécifiques sont partagés de manière contrôlée.

Disponible en due diligence contrôlée
  • Vue architecture & dataflow
  • Matrice rôles & autorisations
  • Résumé des limites sécurité
  • Hébergement, sous-traitants & localisation
  • Sauvegarde, continuité & rétention
  • Preuves de tests & acceptance
  • SBOM/informations dépendances si applicable
  • Preuves pentest/certification une fois indépendamment obtenues
Non publié
  • Identifiants, tokens, clés privées et secrets production
  • Inventaire complet des endpoints/routes internes
  • Schémas de données field-level sans nécessité de review
  • Règles exactes firewall et recettes hardening
  • Seuils anti-abus ou logique facilitant un bypass

Une question technique sur un déploiement ?

Utilisez cette page comme première référence technique. Pour les détails spécifiques à un client ou déploiement, nous fournissons une documentation complémentaire de manière contrôlée.

Contact technique →Assurance →