Tourne dans votre plateforme. Sans Internet, si vous le souhaitez.
Ce que les équipes plateforme, sécurité et exploitation veulent savoir avant un pilote, sur une seule page : installation, livraison, modèle d’IA, dimensionnement et rythme des versions.
Ce que votre revue de sécurité demande en premier.
Accès, journal d’audit, durcissement
Rôles et connexion, chiffrement, un journal que la base de données protège elle-même, des versions contrôlées avec SBOM, et la liste franche de ce qui n’existe pas encore.
Auto-évaluation au niveau 2
Les 253 exigences vérifiées une à une par rapport au code, aux tests et à la configuration, avec le résultat par niveau.
Ce que l’IA peut faire et ce qui est stocké
Votre propre fournisseur et votre clé, aucun texte de prompt stocké par défaut, aucun entraînement sur vos données, uniquement dans votre réseau si vous le souhaitez.
Docker Compose ou Kubernetes.
Toute l’application en une seule étape
Pour un pilote, un petit serveur avec 2 vCPU et 4 Go de RAM suffit ; 8 Go sont recommandés. Prérequis, sauvegarde et mise à jour sont décrits.
Un seul namespace, aucun droit à l’échelle du cluster
Chaque conteneur tourne sans root avec un UID fixe, sur un système de fichiers racine en lecture seule et sans capabilities Linux, testé avec Pod Security « restricted ». PostgreSQL et le stockage compatible S3 viennent de votre plateforme ou tournent dans le même namespace. L’accès passe par votre Ingress ou la Gateway API.
Deux voies, toutes deux signées.
Depuis notre registre
Votre plateforme tire les images avec un accès propre à chaque client, que nous pouvons révoquer à tout moment. Ou bien votre miroir, par exemple Harbor ou Artifactory, les récupère pour vous.
Sous forme d’archive de transfert
Chaque version sous forme d’archive avec images, chart Helm, SBOM et résultats d’analyse. Elle se charge dans votre propre registre sans accès Internet.
Chaque image est signée et vérifiable avec notre clé publique, même une fois qu’elle se trouve dans votre registre.
Votre modèle, votre réseau.
Votre propre modèle
Un serveur de modèle à interface compatible OpenAI dans votre propre réseau, testé avec Ollama et llama.cpp. Alors aucun document ne quitte votre environnement. Seul le serveur de modèle a besoin d’un GPU, pas OpsCodex.
Tout autre endpoint
Tout modèle à interface compatible OpenAI, dans votre propre centre de données ou dans le cloud, par exemple d’Anthropic, d’OpenAI, de Google ou de Mistral. Sous votre propre contrat, interchangeable dans l’interface d’administration.
Ce que doit offrir votre propre modèle
Pour vos propres assistants IA, par exemple Microsoft Copilot, il existe une interface MCP : en lecture seule, uniquement les processus approuvés, ouverte jeton par jeton, et chaque accès est journalisé.
Léger et évolutif.
L’IA calcule sur le serveur de modèle, pas dans OpsCodex. C’est pourquoi l’application elle-même reste légère.
Des mises à jour que vous pouvez planifier.
Rythme
Environ une version par trimestre, nommée d’après son mois. Neuf mois de correctifs pour les vulnérabilités élevées et critiques, une journée de correctifs mensuelle, et un correctif critique ne l’attend pas.
Contrôle avant chaque publication
Seul ce qui a réussi le contrôle est publié : démarrage à froid sur des volumes vides, smoke test, analyse de chaque image avec Trivy et attaque de l’extérieur sur l’application en fonctionnement avec OWASP ZAP. Un constat grave arrête la publication. Les images livrées sont exactement celles qui ont été testées, chacune avec sa SBOM.
Vous décidez
Rien ne se met à jour tout seul. Pour chaque version, il est indiqué ce que la mise à jour implique et si un retour arrière est possible sans restaurer la sauvegarde.
En savoir plus sur l’accès, le journal d’audit et ce qui n’existe pas encore : Sécurité → · Évaluer OpsCodex →
Voyez OpsCodex sur l’un de vos propres processus.
Apportez un PDF, une présentation ou une SOP brouillonne, ou utilisez nos données d’exemple. En une heure, le processus est traité de bout en bout : brouillon, approbation, export, et le concierge répond aux questions à son sujet. Vous repartez ensuite avec le processus et un rapport d’analyse.
« Dans nos projets de conseil, nous avons passé des semaines à dépouiller des entretiens, et pourtant, en atelier, chacun décrivait le même processus à sa façon. Les lacunes et les chevauchements n’apparaissaient que tard, et la version approuvée disparaissait dans un référentiel. Nous avons construit OpsCodex pour tout le chemin : du brouillon, en passant par l’optimisation, jusqu’au travail qui vient ensuite. »
Tillmann Schatz · Product Owner OpsCodex, Senior Manager chez Mews PartnersOpsCodex est développé par une équipe de Mews Partners.