En vigueurDécidée le 12 octobre 2026 · Réf. RF-102
Interface : relecture seulement quand les données changent
- Ce que fait l'outil
- Les écrans ne se relisent que si les données ont réellement changé (une empreinte légère est relevée régulièrement) ; une écriture faite depuis la session relit aussitôt. Une session lit la base par une connexion en lecture seule, ouverte le temps d'un affichage. Une version du moteur qu'on n'a pas pu contrôler est traitée comme incompatible, avec une alerte. Les essais de connexion échoués sont comptés et bornés, et l'écran dit combien de temps attendre.
- Pourquoi
- Relire à heure fixe rouvrait la base des dizaines de fois par affichage, et tenir une connexion plus longtemps empêcherait d'écrire. Un contrat qu'on n'a pas pu lire n'est pas un contrat compatible.
En vigueurDécidée le 11 octobre 2026 · Réf. RF-052
Interlocuteur imprimé sur les documents envoyés au fournisseur
- Ce que fait l'outil
- La demande de reprise et le pied de page du dossier de négociation impriment une fonction (« Service achats », ou son équivalent dans la langue du document), jamais l'identifiant de l'acheteur. Un réglage permet de rétablir l'identifiant de l'acheteur.
- Pourquoi
- Un document envoyé hors de l'entreprise ne doit pas porter de donnée personnelle qui n'y est pas nécessaire (RGPD).
En vigueurDécidée le 11 octobre 2026 · Réf. RF-072
Entité raccordée par Snowflake, en lecture seule
- Ce que fait l'outil
- Une entité dont les données ERP sont dans un entrepôt Snowflake se raccorde par configuration : une requête déclarée par jeu de données, un rôle dédié et une paire de clés. Les rôles d'administration et le mot de passe sont refusés ; chaque requête est une lecture unique, contrôlée avant exécution. Un jeu se lit en entier ou pas du tout. Un essai à blanc vérifie la connexion, le rôle, ses droits et les colonnes, sans lire de données ni rien écrire. Éprouvé en simulation ; l'essai sur un compte réel reste à faire.
- Pourquoi
- Le compte de l'outil ne doit rien pouvoir modifier dans l'entrepôt du groupe, et un jeu tronqué ferait lire une absence comme un retrait.
En vigueurDécidée le 11 octobre 2026 · Réf. RF-084
Mode simulé de l'ERP : jamais par défaut, toujours signalé
- Ce que fait l'outil
- Pour préparer un raccordement, l'outil peut lire un ERP fictif dans une base locale, avec les mêmes requêtes et les mêmes contrôles. Ce mode n'est jamais actif par défaut ; il est refusé dès qu'une entité réelle ou des données réelles sont présentes, et il est signalé partout où il agit (synchronisations, rapports, essai à blanc).
- Pourquoi
- Des données fictives mêlées à celles d'un site réel ne pourraient plus en être séparées, et un rapport « tout est vert » sur une simulation ne prouve rien d'un raccordement réel.
En vigueurDécidée le 10 octobre 2026 · Réf. RF-060
Purge de la base de démonstration
- Ce que fait l'outil
- Seul un administrateur peut purger une base de démonstration ou de test : autorisation de l'exploitation, plan, motif, phrase de confirmation et sauvegarde vérifiée avant toute suppression. L'exploitation peut rétablir l'approbation d'un second administrateur.
- Pourquoi
- Les verrous existants suffisent pour une base de démonstration ; un second administrateur en bloquait l'usage.
En vigueurDécidée le 12 octobre 2026 · Réf. RF-073
Base de données choisie à l'installation
- Ce que fait l'outil
- La base (DuckDB ou PostgreSQL) se choisit à l'installation ; DuckDB est le défaut. Le passage à PostgreSQL est une migration à sens unique, accompagnée selon un processus écrit : chaque table est recopiée en entier, ses lignes comptées et ses totaux comparés ; au moindre écart, la migration est refusée et DuckDB reste la base. La base d'origine est gardée intacte. Une vérification d'exploitation recommande la migration au-delà de certains seuils, sans rien basculer d'elle-même.
- Pourquoi
- Basculer à chaud montrerait une base vide ou deux bases divergentes ; une migration non vérifiée pourrait perdre un historique sans que personne ne le voie.
- Où le voir
- Entités, ERP et taux
- Base de données
En vigueurDécidée le 12 octobre 2026 · Réf. RF-090
Paramètres de la base modifiés par l'administrateur, avec garde-fous
- Ce que fait l'outil
- Seul l'administrateur modifie les paramètres de connexion à PostgreSQL. Il s'authentifie de nouveau (mot de passe, ou code à usage unique d'une application d'authentification derrière le portail de l'entreprise). Un test de connexion précède toute application ; une alerte rappelle sa responsabilité et demande une confirmation explicite. Le mot de passe n'est jamais affiché ni stocké en clair. Chaque modification est tracée et l'ancienne configuration se rétablit d'un geste. Un changement sur la base en service passe par le mode maintenance.
- Pourquoi
- Un mauvais paramètre arrête l'outil pour tout le monde, et un changement fait pendant que d'autres écrivent peut perdre des données. Le test, la confirmation et la maintenance empêchent l'erreur ; la trace et le rétablissement la réparent.
En vigueurDécidée le 11 octobre 2026 · Réf. RF-083
Traduction de l'interface : aucun service externe
- Ce que fait l'outil
- Le français est la langue source. Chaque texte a une clé stable, dans une base unique de fichiers, un par langue. Une traduction manquante n'est jamais une clé brute ni un blanc : l'interface affiche le texte français et le signale. Aucune traduction n'est demandée à un service externe. Ajouter une langue se fait sans toucher au code. Vos données (fournisseurs, désignations, références) ne sont jamais traduites.
- Pourquoi
- Un outil d'achats utilisé dans plusieurs pays doit parler la langue de chacun sans que les textes partent hors de l'entreprise ni qu'un texte absent casse l'écran.
En vigueurDécidée le 11 octobre 2026 · Réf. RF-081
L'adresse MAC du poste n'est jamais collectée
- Ce que fait l'outil
- Le journal des exports et de l'archivage n'écrit jamais d'adresse MAC, à aucun niveau de traçabilité, et aucun réglage ne permet d'en transmettre une. Au niveau le plus complet, le journal note l'adresse IP, tronquée, et rien d'autre sur le poste.
- Pourquoi
- Derrière le serveur intermédiaire, l'application ne voit pas l'adresse MAC du poste : la valeur écrite serait fausse. La minimisation du RGPD va dans le même sens.
En vigueurDécidée le 12 octobre 2026 · Réf. RF-096
Adresse IP du journal des exports : absente par défaut, tronquée, 12 mois au plus
- Ce que fait l'outil
- Par défaut, aucune adresse IP n'est collectée, même fournie. Au niveau « complet », choisi par votre informatique, seule l'adresse tronquée est écrite (IPv4 au /24, IPv6 au /48) ; l'adresse complète n'existe dans aucune ligne. La ligne porte sa finalité (« sécurité ») et sa date de fin de conservation : 12 mois au plus. Les lignes échues sont proposées à la purge ; le journal chaîné n'est jamais réécrit par l'outil.
- Pourquoi
- Une adresse IP est une donnée personnelle ; la minimisation du RGPD demande de ne garder que ce qui sert, et la finalité de sécurité se satisfait d'une adresse tronquée. Votre service juridique relit la durée et la finalité avant tout usage au niveau « complet ».
En vigueurDécidée le 12 octobre 2026 · Réf. RF-097
Durées de conservation par type de document
- Ce que fait l'outil
- Factures, commandes et réceptions : 10 ans après la clôture de l'exercice. Tarifs, contrats et courriers : durée du contrat plus 5 ans. Journaux techniques : 12 mois. Chaque document archivé porte une étiquette de conservation (type de durée, base de calcul, date de fin). Une base inconnue (clôture non déclarée, fin de contrat inconnue) laisse la date de fin vide avec son motif : elle n'est jamais devinée et le document n'est jamais proposé à la suppression.
- Pourquoi
- Une date de fin devinée ferait supprimer trop tôt une preuve comptable ou contractuelle. Ces durées sont à faire relire par votre service juridique.
En vigueurDécidée le 12 octobre 2026 · Réf. RF-098
L'outil propose, la DSI supprime
- Ce que fait l'outil
- La liste des échéances de conservation est en lecture seule : elle propose, elle ne supprime jamais rien. La suppression reste un acte de la DSI, tracé au journal, qui exige un réglage actif, une règle de durée écrite, un droit dédié, un motif, une confirmation et la relecture juridique inscrite ; sans elle, la confirmation est refusée. Un document sans date de fin, pas encore échu ou sous conservation légale n'est jamais supprimé.
- Pourquoi
- L'outil propose, la DSI exécute avec trace, et tant que le juridique n'a pas relu les durées, rien n'est supprimé.
En vigueurDécidée le 19 octobre 2026 · Réf. RF-147
Le journal des exports est découpé en mois scellés, la DSI supprime un mois échu à la main
- Ce que fait l'outil
- Le journal des exports et de l'archivage est coupé en un fichier par mois. Chaque mois fermé reçoit un sceau (période, nombre de lignes, première et dernière empreinte, empreinte du fichier) gardé dans un fichier à côté, dans la base et, si un datalake est déclaré, dans le datalake ; la première ligne du mois suivant reprend l'empreinte finale du précédent, et aucune ligne existante n'est jamais réécrite. Un mois devient supprimable 12 mois révolus après son dernier jour. La suppression est un acte manuel de la DSI, jamais automatique : réservée à l'administrateur, avec droit dédié, motif et confirmation (sinon un simple aperçu), sur le mois le plus ancien et seulement si le juridique a relu les durées ; sinon refus, tracé. Le sceau reste, la vérification de la chaîne repart de lui, et un mois qui disparaît sans suppression enregistrée est signalé comme une rupture. Conséquence : une ligne peut être gardée jusqu'à 13 mois au lieu de 12, ce que le juridique doit trancher.
- Pourquoi
- Retirer des lignes échues en coupant le début d'un journal chaîné casserait la chaîne d'empreintes. Des mois scellés se suppriment entiers, le sceau garde la preuve, et rien ne disparaît sans décision humaine, tracée, après la relecture du juridique.
En vigueurDécidée le 12 octobre 2026 · Réf. RF-103
Dimensionnement de la base fondé sur des mesures
- Ce que fait l'outil
- La recommandation de taille de la base se fonde sur des temps d'attente mesurés sur une copie de la base, avec le service réel : écriture sous 2 secondes et lecture sous 1 seconde pour 95 % des demandes. Toute valeur de dimensionnement non mesurée est écrite « estimée », avec son mode de calcul. PostgreSQL alimenté par DuckDB se choisit pour le volume, la reprise sur panne et la sauvegarde, pas pour tenir plus d'utilisateurs.
- Pourquoi
- Migrer pour résoudre une attente qui ne vient pas de la base coûterait une migration sans effet, et des chiffres non mesurés présentés comme exacts feraient acheter à tort.
En vigueurDécidée le 13 octobre 2026 · Réf. RF-105
Formats d'affichage selon la langue ; la devise suit la donnée
- Ce que fait l'outil
- Nombres, montants, dates et pourcentages s'affichent selon la langue de l'écran (séparateurs, noms des mois, place du symbole). La devise d'un montant vient toujours de la donnée : changer de langue déplace le symbole, jamais la devise. Les fichiers produits pour d'autres outils (extractions, export ERP, classeurs) gardent leur format, quelle que soit la langue de l'écran.
- Pourquoi
- Un montant en livres affiché en euros parce que l'écran est en français, ou un export ERP dont le séparateur décimal change selon la langue de la personne qui l'a produit, fausseraient une comparaison de prix ou un chargement dans l'ERP sans que rien ne le signale.
En vigueurDécidée le 13 octobre 2026 · Réf. RF-106
Langue de l'interface : le choix du profil d'abord
- Ce que fait l'outil
- La langue d'une session suit le choix enregistré dans le profil de la personne, sinon celle du navigateur, sinon le français. Chacun choisit sa langue dans le menu Affichage ; le choix ne change ni ses droits ni ses données. Un texte affiché en français faute de traduction n'est marqué « [FR] » que pour l'administrateur, jamais dans les fichiers produits.
- Pourquoi
- Une personne qui travaille en allemand ne doit pas retomber en français parce qu'elle change d'ordinateur ; un marqueur visible de tous ferait douter de l'outil, alors que l'administrateur en a besoin pour repérer ce qui reste à traduire.
En vigueurDécidée le 13 octobre 2026 · Réf. RF-111
La suite de tests se joue aussi sur PostgreSQL
- Ce que fait l'outil
- La suite de tests de l'outil se joue sur les deux moteurs de base. Les tests qui passent déjà sur PostgreSQL natif forment une liste versionnée : un test de cette liste qui échoue fait échouer la suite, et un test qui passe hors liste est signalé pour y entrer. Sans serveur PostgreSQL, l'essai s'arrête au lieu de sauter tous les tests. La suite ordinaire reste inchangée.
- Pourquoi
- Traduire toutes les vues et les requêtes sans régression silencieuse demande de savoir, test par test, ce qui marche déjà, et de ne jamais perdre un test une fois passé.
En vigueurDécidée le 13 octobre 2026 · Réf. RF-110
Une couche d'accès unique ; PostgreSQL natif encore refusé
- Ce que fait l'outil
- Tout accès de l'outil à sa base passe par une couche unique, prévue pour DuckDB (le défaut) et pour PostgreSQL par un pilote natif. Tant que les vues et les requêtes ne sont pas toutes traduites pour PostgreSQL, ce mode natif est refusé avec un message qui dit pourquoi et quoi déclarer à la place ; l'outil n'ouvre jamais une autre base à sa place. Le pilote est une dépendance optionnelle, chargée comme bibliothèque séparée.
- Pourquoi
- Passer à PostgreSQL par étapes sans casser l'existant suppose un seul endroit où l'on change de moteur. Accepter le nouveau moteur avant que tout soit traduit servirait des erreurs au lieu d'un refus clair.
En vigueurDécidée le 20 octobre 2026 · Réf. RF-158
Un client neuf démarre directement sur PostgreSQL, sans jamais écraser une base
- Ce que fait l'outil
- Un client neuf, sans aucune donnée, peut démarrer sur PostgreSQL dès le premier jour, sans passer par la migration : un aperçu en clair dit d'abord ce qui sera créé, puis l'administrateur confirme. L'outil refuse de créer dans une base qui contient déjà des données et renvoie vers la migration. Il vérifie la base créée, pose les index et recommande des réglages pour le serveur PostgreSQL, sans jamais les appliquer lui-même.
- Pourquoi
- Passer par DuckDB puis par la migration serait un détour pour un client qui n'a rien à copier, mais créer sans garde-fou risquerait d'écraser un jour une base remplie. L'exploitation reste maître de son serveur : l'outil conseille, il ne touche pas à sa configuration.
En vigueurDécidée le 13 octobre 2026 · Réf. RF-109
Index de la base PostgreSQL : jamais une migration refusée par un index
- Ce que fait l'outil
- Les index de la base PostgreSQL sont écrits dans un script versionné et posés table par table, juste après la copie et la vérification de chaque table. Un index d'unicité n'est posé que sur une clé que l'outil garantit, après avoir compté les doublons sur les données réelles : s'il y en a, l'index est posé sans unicité et le rapport le dit. Un index ne fait jamais échouer une migration.
- Pourquoi
- Sans index, chaque lecture filtrée relit toute la table. Mais un index d'unicité posé sur une clé que les données contredisent ferait échouer la migration : la vérification passe avant, et l'écart est signalé, pas caché.
En vigueurDécidée le 13 octobre 2026 · Réf. RF-108
Service moteur : les lectures ensemble, chaque écriture seule
- Ce que fait l'outil
- Le service qui protège la base laisse passer plusieurs lectures en même temps, chacune en lecture seule, et fait passer chaque écriture seule. Dès qu'une écriture attend, les lectures arrivées après elle attendent qu'elle soit passée ; personne n'attend indéfiniment. Une lecture faite juste après une écriture voit ce qui a été écrit. Seules des commandes dont il est prouvé qu'elles n'écrivent jamais passent avec les lectures, et la base leur est ouverte en lecture seule.
- Pourquoi
- Un verrou unique faisait attendre les lectures derrière les écritures, alors que la plupart des demandes sont des lectures. Laisser les lectures passer ensemble supprime cette attente sans risque pour les données, puisque chaque écriture reste seule.
En vigueurDécidée le 18 octobre 2026 · Réf. RF-130
Un monde de démonstration tiré au hasard, mais que l'on peut rejouer
- Ce que fait l'outil
- L'administrateur peut remplacer les données de la démonstration par un monde fictif tiré au hasard : fournisseurs, articles, prix, exports ERP de plusieurs sites et tarifs traités par les mêmes commandes que les écrans. Il choisit une graine et une taille ; les mêmes valeurs redonnent exactement le même monde. Le chargement passe par la purge de la base, avec tous ses verrous, une sauvegarde vérifiée et un refus en production. Cette fonction est éteinte dans une livraison client : elle ne sert qu'aux environnements de formation et de démonstration.
- Pourquoi
- Pour montrer l'outil sur des données variées sans jamais recopier de données réelles, et pour refaire à l'identique une démonstration réussie, sans que l'écran puisse vider une base de production.
En vigueurDécidée le 18 octobre 2026 · Réf. RF-149
Un guide Word par poste, toujours à jour avec l'outil
- Ce que fait l'outil
- Chaque profil dispose de son guide : mission, journée, écrans, droits, échanges avec les autres rôles et parcours d'exercices pour se former. Une carte des rôles montre qui dépend de qui, et un guide de déploiement dit dans quel ordre mettre l'outil en service. Les guides sont générés à partir de l'outil lui-même : ils ne peuvent pas dire autre chose que l'application.
- Pourquoi
- Pour former une équipe poste par poste, sans manuel de plusieurs milliers de lignes, et sans guide qui devient faux dès que l'outil change.
En vigueurDécidée le 19 octobre 2026 · Réf. RF-150
Les réglages simples se posent depuis un seul écran, avec un droit fermé par réglage, un motif et un historique annulable
- Ce que fait l'outil
- Chaque réglage simple (un nombre, un oui/non, un choix dans une liste fermée) est déclaré une fois pour toutes dans le moteur. L'écran « Paramétrage » montre, pour chacun, la valeur en vigueur, d'où elle vient (valeur d'origine, fichier du client, réglé ici, fournisseur, entité) et la valeur d'origine. Pour modifier un réglage, il faut un profil autorisé pour CE réglage, une valeur dans les bornes (refusée sinon, jamais corrigée) et un motif d'au moins 10 caractères. Chaque modification est une nouvelle version dans l'historique et peut être annulée ; deux personnes qui modifient le même réglage en même temps ne s'écrasent pas. La valeur la plus précise l'emporte : celle d'un fournisseur ou d'une entité passe avant celle de toute la société. Une valeur absente est la valeur d'origine, jamais zéro. Une nouvelle valeur s'applique aux campagnes suivantes ; celles déjà produites ne changent pas.
- Pourquoi
- Pour qu'intégrer un nouveau client ne demande plus d'éditer des fichiers sur un serveur sans trace : chaque réglage a la même garantie que les cartes de réglage existantes, sans écran supplémentaire à écrire pour chacun.
En vigueurDécidée le 20 octobre 2026 · Réf. RF-159
Les tarifs fictifs ne se fabriquent et ne se déposent que sur une base de démonstration, sans jamais prendre de décision
- Ce que fait l'outil
- L'outil peut fabriquer à la demande des tarifs fournisseurs fictifs et réalistes (hausse, baisse, formats de fichier variés, erreurs, décalages de dates) pour essayer l'analyse, les alertes et l'export. Il ne fonctionne que sur une base de démonstration ou d'essai : sur une base réelle, l'application refuse avant toute lecture ou écriture, et l'écran ne propose rien. Le tarif est déposé comme n'importe quel autre, de façon annulable et tracée avec un motif ; l'acheteur décide ensuite à l'écran. Un fichier d'attendus dit ce que l'outil doit retrouver.
- Pourquoi
- Des prix inventés mélangés à de vrais prix dans une base qui ne s'efface pas seraient irréparables : le verrou est donc dans l'application elle-même, pas seulement dans l'écran. On peut ainsi tester tout le parcours sans donnée réelle.
Décidée, à livrerDécidée le 26 octobre 2026 · Réf. RF-176
La base se lit en SQL, en lecture seule, par l'administrateur et l'architecte : livré pour l'administrateur, une requête à la fois, bornée, interrompue au bout de dix secondes et tracée
- Ce que fait l'outil
- La base peut être interrogée en SQL, en lecture seule, sans jamais être modifiée, par l'administrateur et par l'architecte. Cette lecture est livrée pour l'administrateur seul, par une commande du moteur ; l'écran viendra ensuite. L'architecte y accédera quand un filtre vérifiable cachera les prix de rétrocession, qu'il ne voit jamais ; d'ici là le moteur le refuse. Le droit est contrôlé par le moteur lui-même, pas seulement par l'écran, d'après le registre des comptes ; un compte inconnu ou désactivé est refusé. Une requête est une seule instruction de lecture : écriture, création, suppression, réglage, lecture d'un fichier ou du réseau, et deux instructions à la suite sont refusées. Seules se lisent les vues de l'interface ; une table brute, une vue interne ou le catalogue du moteur sont refusés, où qu'ils se cachent dans la requête. Le résultat est limité (mille lignes par défaut, cinq mille au plus, vingt mégaoctets au plus, avec l'indication « tronqué » et sa raison), la requête est interrompue au bout de dix secondes, et une valeur absente reste absente, jamais zéro. Chaque appel, accepté ou refusé, laisse une ligne dans le journal chaîné (qui, quelle requête, combien de lignes, combien de temps, quelle issue sous la forme d'un code fermé), jamais le contenu du résultat ni un message d'erreur du moteur.
- Pourquoi
- La base contient des données commerciales qui ne sont pas visibles de tous les profils. Une requête libre contournerait les règles de masquage de l'interface : le moteur réserve donc pour l'instant cette lecture à l'administrateur, la borne, et en garde la trace.
En vigueurDécidée le 26 octobre 2026 · Réf. RF-180
Une entité peut être déclarée « de démonstration » : elle est comptée à part dans les mesures de santé du système, jamais mêlée aux totaux réels
- Ce que fait l'outil
- Une entité peut être déclarée « de démonstration » dans la configuration, par une simple propriété vrai ou faux (faux si elle n'est pas déclarée). L'outil la montre telle quelle dans la liste des entités, jamais vide, et une valeur qui n'est ni vraie ni fausse est refusée à la vérification de la configuration : l'entité reste alors une entité réelle. Une base déjà en service reçoit la propriété à faux pour toutes ses entités. L'écran « Santé du système », réservé à l'administrateur et au data architecte, compte les entités de démonstration à part et ne les mêle jamais aux totaux des entités réelles : un bloc replié les liste avec leurs échecs attendus. Le monde de démonstration marque ainsi toutes ses entités de cas d'erreur voulus, et elles seules.
- Pourquoi
- Le monde de démonstration contient des entités volontairement en échec. Sans signal explicite, un écran de santé du système les compterait comme de vraies pannes : c'est celui qui construit la démonstration qui dit quelles entités sont fictives.
En vigueurDécidée le 21 octobre 2026 · Réf. RF-160
Chacun choisit son affichage, et ses choix le suivent d'un poste à l'autre
- Ce que fait l'outil
- Le menu « Affichage » offre à chaque personne cinq choix, gardés sur son propre compte : la page d'accueil (« À faire » ou « Synthèse »), les menus (détaillés, avec une ligne d'explication sous chaque écran, ou compacts), les compteurs de la barre (combien de tâches déduites attendent derrière l'accueil, chaque menu et chaque écran), les aides des écrans (repliées ou toujours ouvertes) et la densité. Un bouton rétablit les réglages par défaut. Ce sont des préférences, pas des droits : elles ne changent ni ce que la personne a le droit de voir, ni les données, et un compteur ou une carte ne mène jamais vers un écran que le profil n'a pas. En tête de « À faire », une carte par écran dit combien de tâches l'attendent et ce qu'elles pèsent, et l'ouvre d'un clic.
- Pourquoi
- Une journée d'acheteur passe d'un écran à l'autre : rien dans la barre ne disait où était le travail, et les encadrés d'explication repoussaient le contenu utile sous la ligne de flottaison. Celui qui débute veut les aides ouvertes, celui qui sait veut une barre sobre : chacun règle son écran sans toucher à celui des autres.
En vigueurDécidée le 21 octobre 2026 · Réf. RF-161
La charge de l'ERP est planifiée par l'outil, à des horaires réglables, sans bloquer les utilisateurs
- Ce que fait l'outil
- Un planificateur intégré à l'outil décide quand recopier les données de chaque ERP, par entité et par famille de données : une fois par jour, toutes les 2 h, toutes les heures, toutes les 30 min ou un nombre de minutes, dans une fenêtre horaire, certains jours, à l'heure de l'entité. Hors fenêtre rien ne se lance, et au retour un seul passage rattrape. L'ERP est lu sans bloquer personne ; seule la courte écriture finale prend la main, et sa durée est mesurée et affichée. Une source inchangée ne coûte aucune écriture. Jamais deux charges en même temps, jamais pendant une sauvegarde. Les ventes sont copiées en agrégat journalier, jamais mouvement par mouvement. Le planificateur est coupé tant qu'on ne l'allume pas.
- Pourquoi
- Une charge qui lit l'ERP en tenant la main bloque tous les utilisateurs pendant sa durée (6 secondes à 100 000 articles, une demi-minute à 500 000). Lire sans verrou, ne rien écrire quand rien n'a changé et régler les horaires limitent la charge de calcul et la croissance de la base.
En vigueurDécidée le 21 octobre 2026 · Réf. RF-165
Le monde d'essai n'avance que par ce qui change ; un passage sans rien à faire ne touche à rien
- Ce que fait l'outil
- Le monde d'essai fait vivre les sept sites fictifs qui commands chez leurs fournisseurs. Il avance d'un pas : un jour clos au pas jour, un mois clos au pas mois. Un passage où aucun jour n'est dû ne fait rien du tout : rien n'est rejoué, rien n'est réécrit, l'essai reste exactement où il en était. Un passage où des jours sont dus n'écrit plus toute l'histoire depuis le premier jour : il n'écrit que ce qui a changé depuis le dernier passage (les prix saisis par les sites, les nouvelles commandes, factures et volumes, les ventes du mois en cours, le stock du dernier jour). Le résultat est celui d'un jeu complet : mêmes données, mêmes fichiers, même journal, même vérité. Si le dossier de l'ERP simulé ne correspond plus à l'état du monde (monde copié sans son ERP, ERP remplacé à la main), le jeu complet est refait : l'essai ne montre jamais un mélange de deux histoires. À graine fixée, la même histoire, jour par jour ou d'un seul tenant, donne le même résultat.
- Pourquoi
- Chaque passage rejouait le monde depuis son premier jour, alors que la plupart des nuits n'avaient rien à faire : sur le poste le plus rapide, un passage de rien coûtait déjà plus de six secondes avec trois ans d'historique, et l'écriture complète de l'ERP depuis l'origine représentait les deux tiers du temps d'un passage (le serveur, au disque plus lent, y était bien plus pénalisé, un passage par nuit). L'essai doit avancer vite et ne jamais mélanger deux histoires.
En vigueurDécidée le 21 octobre 2026 · Réf. RF-164
Les raisons affichées par l'outil sont un code, traduit dans la langue de l'utilisateur
- Ce que fait l'outil
- Quand l'outil explique une ligne — une économie, un classement, une alerte réveillée, un taux, une suspension, un dépôt refusé — il écrit un code et garde la phrase française comme référence. L'interface lit ce code dans le catalogue des traductions : en français, la phrase de l'outil, mot pour mot ; dans les autres langues, sa traduction. Une raison que le catalogue ne connaît pas reste affichée telle quelle, jamais vide, jamais sous la forme d'une clé technique.
- Pourquoi
- Un utilisateur dont la langue n'est pas le français lisait du français au milieu de ses lignes. Reconnaître la phrase pour la traduire est fragile : un mot de plus et le français revient. Le code ne bouge pas, et la phrase française affichée ne change pas.
