Ce qu’un pilote doit mesurer

1. Avec quelle exactitude lit-il vos SOP réelles ?

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.

2. Combien de temps de modélisation fait-il réellement gagner ?

Nous ne publions aucun chiffre de gain de temps, faute de mesure issue de votre environnement — et une mesure issue du nôtre ne serait pas transposable.

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.

3. Les exports s’ouvrent-ils proprement dans votre outil cible ?

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.

4. La piste d’audit est-elle infalsifiable, ou seulement en lecture seule dans l’interface ?

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.

5. Tourne-t-il vraiment dans votre environnement ?

OpsCodex se déploie en mono-tenant, on-premise. Le minimum documenté pour un hôte pilote :

Hôte

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 : ni cluster Kubernetes, ni services managés.

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.

Identité

SSO contre votre propre fournisseur d’identité via SAML/OIDC, avec MFA imposée avant qu’une requête n’atteigne l’application. Testez-le pendant le pilote avec votre IdP réel, pas avec des comptes locaux — c’est là que les déploiements on-premise calent le plus souvent.

Ces chiffres sont volontairement modestes. Tout l’intérêt de l’on-premise est que vous fournissez l’hôte : moins il demande, plus vite votre équipe infrastructure dit oui — aucun cluster à monter, aucun service managé à acheter. La vraie question est ce qui vient après le pilote, et la réponse honnête est celle-ci : la discipline d’exploitation est documentée, la montée en charge ne l’est pas.

Sauvegarde et restauration

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.

Mises à jour et retour arrière

Les versions sont épinglées et non flottantes, et 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. C’est ce qui fait du retour arrière une procédure et non un espoir.

Multi-nœuds et bascule

Ce n’est pas quelque chose que nous proposons aujourd’hui. Ce qui est documenté et pris en charge, c’est un hôte unique. 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.

6. Combien cela coûte-t-il au total ?

Il n’existe pas de grille tarifaire publiée ; plutôt que d’en inventer une, nous décrivons 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 ou VM, 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.

7. Que se passe-t-il si l’éditeur disparaît ?

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.