Ce qu’un pilote doit mesurer

C’est la question dont tout le reste dépend, et la seule à laquelle nous ne répondrons pas par un chiffre. La qualité d’extraction dépend de la rédaction de vos documents : une SOP structurée, avec des étapes numérotées et des rôles nommés, n’a rien à voir avec une présentation faite de cases et de flèches. Tout éditeur citant un taux de précision unique le cite sur son propre corpus, pas sur le vôtre.

Comment le mesurer : prenez cinq documents réellement représentatifs, dont un que vous jugez mal rédigé. Faites annoter les brouillons par un responsable de processus qui connaît le déroulé réel. Comptez séparément ce qui compte : rôles, décisions (passerelles), chemins d’exception et boucles. C’est sur les exceptions et les boucles que la conversion document-vers-modèle se dégrade habituellement — le chemin nominal est la partie facile.

Ce que nous pouvons affirmer : la sortie de l’IA est un brouillon, jamais un modèle approuvé. Le Process Advisor contrôle chaque brouillon au regard de la conformité BPMN et des règles de nommage et propose des corrections en un clic ; les erreurs structurelles apparaissent donc avant la relecture, pas pendant. La question restante — l’exactitude sémantique — est précisément la raison d’être de la relecture humaine obligatoire.

Notre propre test : en moyenne environ 70 % de temps en moins jusqu’au modèle prêt pour la relecture. Ce que vous gagnez sur l’ensemble du trajet jusqu’à l’approbation, seule une mesure sur vos propres processus peut le montrer.

Comment le mesurer : modélisez deux de ces cinq processus à la main, comme aujourd’hui, chronomètre en marche. Faites ensuite passer les cinq par OpsCodex et mesurez le trajet de l’ingestion à l’approbation. Mesurez le trajet complet, pas l’étape de rédaction : le brouillon est rapide dans n’importe quel outil d’IA ; ce qui distingue les outils, c’est la reprise que ce brouillon impose et la durée de l’approbation une fois les relecteurs désignés.

OpsCodex modélise en BPMN 2.0 et exporte du BPMN XML conforme à la spécification de l’OMG. L’intention : que les processus approuvés restent portables — tout outil conforme BPMN doit pouvoir lire ce qu’OpsCodex écrit.

Comment le vérifier : exportez les modèles approuvés de votre pilote et ouvrez-les dans ce que vous utilisez vraiment — Camunda, Signavio, ARIS, un visualiseur basé sur bpmn.io. Vérifiez que la mise en page survit, pas seulement la sémantique. Les informations de mise en page voyagent dans la section BPMN DI, et les outils la respectent plus ou moins fidèlement. Faites-le pendant le pilote, pas après le déploiement.

Question légitime, et les deux choses sont très différentes. Dans OpsCodex, la garantie append-only est imposée dans la base de données, pas dans le code applicatif : un trigger sur la table d’audit rejette tout UPDATE et tout DELETE, et le rôle de base de données sous lequel tourne l’application s’est vu retirer ces droits. L’application ne peut pas réécrire son propre historique, même compromise.

La limite, dite clairement : le trigger couvre la modification et la suppression au niveau des lignes. Il ne couvre pas TRUNCATE, et aucun contrôle applicatif ne résiste à un accès superutilisateur à votre propre serveur de base de données. La description complète est sur la page sécurité.

Comment le vérifier : dans votre instance pilote, connectez-vous avec l’utilisateur de base de données de l’application et tentez de modifier ou supprimer une ligne d’audit. Cela doit échouer. C’est une vérification de cinq minutes, et elle vaut mieux que de croire cette page.

OpsCodex se déploie en mono-tenant, on-premise, de l’une de deux façons : Docker Compose sur un seul hôte, ou un chart Helm sur votre plateforme Kubernetes. Ce que chacune demande :

Hôte pour Docker Compose

Linux (testé sur Debian/Ubuntu), 2 vCPU et 4 Go de RAM au minimum — 4 vCPU et 8 Go recommandés dès que les fonctions d’IA sont utilisées régulièrement. 20 Go d’espace disque libre pour la base, les téléversements et le contenu documentaire.

Exécution

Docker 24+ avec Compose v2. Un seul hôte suffit pour un pilote — aucun cluster à monter, aucun service managé à acheter.

Kubernetes

Kubernetes 1.25 ou plus récent, Helm 3.8 ou plus récent. Le chart s’installe dans un seul namespace sans droits à l’échelle du cluster, fait tourner chaque conteneur sous un utilisateur non root sur un système de fichiers racine en lecture seule, et est testé avec le standard Pod Security restricted imposé. PostgreSQL et S3 viennent de votre plateforme ou tournent dans le même namespace. Les détails figurent sur la page sécurité.

Réseau

Accessible sur votre réseau local. Aucun accès Internet entrant n’est requis. La seule dépendance sortante est l’inférence IA — vers le fournisseur que vous choisissez, avec votre clé, ou vers un point de terminaison privé que vous hébergez.

Les chiffres pour Compose sont volontairement modestes : moins un hôte pilote demande, plus vite votre équipe infrastructure dit oui. La vraie question est ce qui vient après le pilote :

Combien de personnes une installation supporte

Mesuré, pas estimé. Dans un test de charge du chart Kubernetes avec ses limites de ressources par défaut, 700 personnes travaillant en même temps — actives dans les mêmes minutes, pas des comptes ; 70 % lisent le portail, 25 % modélisent, 5 % exportent — sont restées sous chaque seuil fixé avant le premier essai : 95 % des appels interactifs en moins d’une demi-seconde, les pages en moins de deux secondes, les exports en moins de 15 secondes, moins de 1 % d’erreurs. La première limite atteinte a été le CPU du backend ; la mémoire et la base de données en sont restées loin. L’import de documents par l’IA ne faisait pas partie du test, car la génération tourne sur votre service de modèles, pas dans OpsCodex.

Sauvegarde et restauration

Avec Docker Compose, un script de sauvegarde écrit un instantané horodaté de la base, du stockage des fichiers et de la configuration, avec les tailles et les empreintes SHA-256 consignées dans un manifeste. Quotidienne au minimum, conservée hors de l’hôte de déploiement. La procédure de restauration est détaillée pas à pas dans le runbook on-premise — demandez-le pendant le pilote et répétez-la à ce moment-là, plutôt que de la découvrir pendant un incident. Sur Kubernetes, les sauvegardes relèvent de la routine de votre plateforme : un instantané de la base et du stockage objet, pris ensemble.

Mises à jour et retour arrière

Les versions sont épinglées et non flottantes. Avec Docker Compose, une sauvegarde est prise automatiquement avant chaque mise à jour — le processus dépend de la réussite de cette sauvegarde et ne se poursuit pas par-dessus un échec. Sur Kubernetes, helm upgrade exécute d’abord la migration de la base dans un Job pendant que l’ancienne version continue de servir ; si la migration échoue, rien d’autre ne change. Les notes de chaque version indiquent si un retour arrière est possible sans restaurer la sauvegarde. C’est ce qui fait du retour arrière une procédure et non un espoir.

Montée en charge et bascule

Sur Kubernetes, la couche web monte en charge horizontalement. Le backend tourne en une seule instance sur les deux plateformes : une mise à jour la remplace, ce qui interrompt l’API quelques secondes — 5 à 12 dans nos mesures — pendant que l’interface reste servie. La bascule de la base de données et du stockage objet relève des services de votre plateforme. Si votre exigence de disponibilité va au-delà, soulevez-la avant le pilote plutôt qu’après — cela change la nature de la discussion sur le déploiement.

Il n’existe pas de grille tarifaire publiée. Voici de quoi le coût est fait : quatre blocs, dont deux que vous pouvez chiffrer dès aujourd’hui :

Infrastructure — chiffrable par vous

Votre propre matériel, VM ou plateforme Kubernetes, selon la spécification ci-dessus. Aucun coût d’infrastructure par utilisateur, aucun hébergement externe.

Usage de l’IA — sous votre contrôle et directement visible

OpsCodex utilise votre compte fournisseur et votre clé. Le coût des tokens vous est facturé directement par Anthropic, OpenAI ou Google — sans marge intégrée à une licence. Vous pouvez le plafonner, le suivre et changer de fournisseur sans nous consulter. Avec un modèle auto-hébergé, ce sont vos propres coûts de calcul.

Licence — sur demande

Chiffrée par projet. Nous préférons la calibrer sur votre déploiement réel plutôt que publier un montant qui ne convient à personne.

Mise en place — sur demande

Dépend du nombre de processus par lesquels vous commencez et de ce qui existe déjà du modèle de gouvernance dans votre organisation.

La question standard face à un petit fournisseur — et elle mérite une réponse directe plutôt qu’un discours rassurant. Deux des trois craintes habituelles ne s’appliquent pas ici, pour des raisons structurelles et non par promesse :

Le système continue de tourner

OpsCodex tourne sur votre matériel, dans votre périmètre. La défaillance de l’éditeur n’éteint rien — contrairement à un produit SaaS, où ce serait une interruption immédiate.

Votre savoir processus part avec vous

Les modèles s’exportent en BPMN 2.0 XML, un standard ouvert de l’OMG lisible par tout outil conforme. Documentation et enregistrements d’audit sont exportables à tout moment. Pour un outil de gouvernance, cela pèse plus lourd que l’accès au code source.

Maintenance et évolution

C’est le point que les deux premiers ne couvrent pas. Abordez-le avec nous au moment de la contractualisation plutôt que de considérer la réponse ci-dessus comme complète.

Une question qui vous importe manque ici ? Posez-la : [email protected]. Celles qui s’avèrent générales viennent enrichir cette page.