Excel et Access sont-ils des systèmes de production ?

Un classeur devient un système de production lorsque l'entreprise attend son résultat. Un fichier Access le devient quand son absence empêche d'accepter une commande, de rapprocher la trésorerie, de planifier le travail ou de clôturer le mois. L'extension du fichier ne rend aucun de ces outils dangereux. La dépendance, l'état partagé et modifiable, les règles cachées et un mode d'exploitation improvisé s'en chargent.

J'ai vu des équipes d'ingénierie réduire ces systèmes à quelques feuilles de calcul jusqu'au matin où une macro s'est arrêtée en pleine clôture. L'équipe financière savait quel onglet ouvrir d'abord, quel avertissement ignorer et pourquoi la valeur de la cellule G47 devait être collée comme valeur avant la seconde exécution. L'ingénierie n'en savait rien. L'entreprise disposait d'un logiciel de production sans jamais l'avoir traité comme tel.

La bonne réponse ne consiste ni à interdire les tableurs ni à remplacer toutes les bases Access. Il faut d'abord déterminer ce qui fait réellement fonctionner l'entreprise. Il faut ensuite saisir ses entrées, son comportement, ses sorties, ses horaires et ses exceptions. Ce n'est qu'alors que vous pourrez le déplacer sans transformer un nettoyage technique en panne opérationnelle.

La dépendance définit un système de production

Excel et Access sont des systèmes de production lorsqu'un processus métier dépend de leur comportement correct et ponctuel, quels que soient leur auteur et l'emplacement des fichiers. Une feuille de calcul réservée à une analyse personnelle est un document. La même feuille devient un système lorsqu'elle reçoit des entrées récurrentes, applique des règles métier, conserve un état, produit un résultat faisant autorité ou déclenche une tâche ailleurs.

La responsabilité constitue un meilleur signal que la complexité. Demandez qui reçoit l'appel lorsque le fichier échoue. Si la réponse désigne un analyste précis, un ancien salarié ou la seule personne qui connaît le mot de passe, vous avez une astreinte que personne n'a documentée. Demandez si l'exécution peut attendre. Si la paie, la facturation, un rapport réglementaire, la sortie d'un entrepôt ou la clôture mensuelle est bloquée, le système a un délai de service même si personne n'emploie cette expression.

Recherchez quatre formes de dépendance :

• Des personnes coordonnent les modifications, les transmissions ou l'ordre d'exécution autour du fichier.
• D'autres fichiers, requêtes, boîtes de réception, exportations ou tâches planifiées l'alimentent ou utilisent son résultat.
• Une formule, une requête, une macro ou une correction manuelle détermine un résultat métier.
• Le fichier conserve la seule copie reconnue d'un état, d'une correspondance, d'une exception ou d'une approbation.

N'évaluez pas le risque uniquement selon la taille du fichier ou le nombre de formules. Un classeur de 20 Ko qui calcule une clause financière peut présenter plus de risque opérationnel qu'un modèle de planification de 200 Mo. De même, un petit fichier Access qui attribue les numéros d'expédition peut compter davantage qu'une grande archive. Le rayon d'impact et le délai de reprise importent plus que les mégaoctets.

Le test gênant reste simple : supprimez mentalement une copie. Si l'équipe peut la recréer depuis une source gouvernée et poursuivre dans le délai habituel, elle est peut-être encore un document. Si les gens doivent fouiller des ordinateurs portables, restaurer la version de la veille, appeler une personne retraitée ou reporter une opération métier, traitez-la comme un système de production.

L'environnement d'exécution dépasse le fichier

Le fichier constitue rarement le système entier. Son environnement d'exécution comprend les partages réseau, les lettres de lecteur mappées, les sources ODBC, les réglages du poste, les compléments, les pièces jointes, les tâches planifiées et la séquence exacte suivie par les personnes. Un inventaire limité aux formules et aux tables rate les dépendances les plus susceptibles de casser pendant le déplacement.

Commencez par une vraie exécution, pas par un atelier d'architecture. Asseyez-vous à côté de l'opérateur et notez chaque entrée ouverte, chaque bouton actionné, chaque invite traitée, chaque fichier renommé et chaque sortie contrôlée. Notez aussi l'heure. Un classeur peut techniquement s'exécuter à tout moment, tout en dépendant dans les faits d'un export nocturne reçu avant 07 h 00 ou d'un grand livre amont devenu immobile après la clôture.

Consignez un journal d'exécution compact pour chaque artefact :

• Entrée : chemin, responsable, format, condition d'arrivée et exemple
• Action : macro, requête, actualisation, collage, modification ou approbation
• État : tables, cellules, fichiers et indicateurs modifiés par l'exécution
• Sortie : destination, consommateur, nombre de lignes attendu et échéance
• Exception : avertissement, nouvelle tentative, correction manuelle et responsable de l'escalade

Répétez l'observation avec un autre opérateur. Les différences sont des exigences. Une personne peut actualiser toutes les connexions avant de lancer la macro. Une autre sait que l'actualisation d'une requête corrompt une table temporaire. Une autre encore filtre par habitude les codes de compte vides. Ces gestes ne sont pas du bruit autour du système. Ils forment des branches de son comportement.

Inspectez au-delà du répertoire évident. Les classeurs lisent souvent un fichier via un lecteur mappé dont la résolution change sur une autre machine. Un frontal Access peut lier des tables issues d'un fichier dorsal dont le chemin est enregistré dans l'application. VBA peut créer des objets à liaison tardive, appeler des programmes en ligne de commande ou enregistrer des fichiers sous des noms dérivés de dates. Une tâche planifiée peut ouvrir le classeur sans interface et dépendre d'un profil de bureau. Documentez la machine et le contexte utilisateur avec le code.

Une règle de périmètre utile consiste à inclure tout élément dont l'absence change le résultat ou arrête l'exécution. L'inventaire reste ainsi pratique. Vous n'avez pas besoin d'un schéma de toute l'informatique financière, mais vous avez besoin de l'export CSV, des paramètres régionaux, du classeur de référence et du dossier partagé que cette exécution suppose.

Les macros Excel contiennent du code opérationnel

VBA, les formules, les étapes Power Query, les plages nommées et les modifications manuelles appliquent tous des règles. Considérer uniquement les macros comme du code produit une fausse carte. Dans les classeurs anciens, la logique traverse ces couches : une requête charge les transactions, des formules les classent, une macro copie certaines lignes et un opérateur remplace deux exceptions avant d'exporter une écriture.

L'état de calcul d'Excel mérite une attention particulière. La documentation de Microsoft sur le recalcul d'Excel décrit les modes automatique, automatique sauf pour les tables de données et manuel. Les instructions d'assistance expliquent aussi que tous les classeurs ouverts partagent le mode de calcul courant et que le premier classeur ouvert influence cet état. Un classeur correct peut donc produire des résultats périmés parce qu'un autre classeur a changé le mode au niveau de l'application. L'enregistrement du fichier peut conserver le mauvais mode pour l'opérateur suivant.

Ne répondez pas en imposant le calcul automatique partout. Les équipes choisissent souvent le calcul manuel parce qu'un grand classeur devient inutilisable pendant le recalcul. Ce correctif répandu masque une exigence de performance et peut modifier l'ordre d'exécution. Identifiez les plages à calculer, le moment du calcul et les sorties vérifiées par l'opérateur avant l'exportation. Rendez ensuite cette séquence explicite dans le remplacement.

Extrayez et classez la logique avant sa réécriture :

1. Repérez les points d'entrée comme les boutons, les événements du classeur, les ouvertures planifiées et les macros nommées.
2. Suivez les lectures et écritures dans les feuilles, plages nommées, requêtes, fichiers externes et connexions de base de données.
3. Signalez les entrées variables, notamment l'heure, l'utilisateur, la feuille active, la sélection, les paramètres régionaux et le chemin du fichier.
4. Séparez les règles déterministes du travail de présentation, comme le formatage et la largeur des colonnes.
5. Consignez chaque dérogation manuelle avec sa raison et son effet en aval.

Une petite sonde placée au début et à la fin d'une macro de clôture mensuelle peut produire des preuves sans la reconcevoir. Le code VBA suivant écrit dans un journal CSV l'horodatage, l'étape, le chemin du classeur, le mode de calcul et la feuille active. Adaptez le chemin et ajoutez des compteurs métier comme le nombre de lignes importées ou le total comptabilisé.

Sub TraceStage(stage As String)
    Dim f As Integer
    f = FreeFile
    Open Environ$("TEMP") & "\close-trace.csv" For Append As #f
    Print #f, Format$(Now, "yyyy-mm-dd hh:nn:ss") & "," & stage & "," & _
        ThisWorkbook.FullName & "," & Application.Calculation & "," & ActiveSheet.Name
    Close #f
End Sub

La sortie prend la forme d'une ligne par étape, par exemple 2026-03-31 18:42:07,after-import,X:\Close\Close.xlsm,-4135,Journal. La valeur -4135 correspond à xlCalculationManual dans Excel. Cette ligne n'explique pas le classeur, mais elle peut réfuter les suppositions sur la copie exécutée, la feuille active et le mode de calcul manuel. Retirez les secrets et les données personnelles avant de conserver ces traces.

La concurrence Access échoue avant les limites publiées

Une base Access partagée peut atteindre ses limites opérationnelles bien avant le maximum publié par Microsoft de 255 utilisateurs simultanés ou de 2 Go par fichier. Ces chiffres décrivent les plafonds pris en charge, pas une capacité à viser. Les vrais problèmes proviennent des écritures concurrentes, du réseau, des transactions longues, des choix de verrouillage et d'un frontal qui garde des tables ou requêtes ouvertes.

Access offre plusieurs comportements de verrouillage. La documentation RecordLocks de Microsoft décrit un comportement optimiste avec No Locks : deux utilisateurs peuvent modifier le même enregistrement et le second reçoit un conflit à l'enregistrement. Edited Record verrouille pendant la modification, mais la documentation précise qu'une page d'enregistrements peut être verrouillée. All Records peut verrouiller l'ensemble sous-jacent pendant qu'un formulaire, un état ou une requête reste actif. Un réglage de formulaire apparemment local peut donc toucher des collègues travaillant ailleurs.

L'expression limite de verrouillage d'enregistrement confond souvent deux pannes. La première est un conflit réel, car deux personnes mettent à jour le même enregistrement métier. La seconde est une contention incidente causée par la façon dont Access regroupe les données, ouvre un jeu d'enregistrements ou exécute une requête d'action. Remplacer le fichier par une base serveur peut réduire les problèmes de partage, mais ne décide pas quelle mise à jour doit gagner. Il faut toujours une règle de concurrence.

Surveillez les symptômes sans attendre un chiffre de capacité :

• Les utilisateurs gardent des copies locales du frontal, car la copie partagée est lente ou fragile.
• Un fichier de verrouillage subsiste après un plantage, ou les opérateurs demandent à tout le monde de quitter avant une réparation.
• Les requêtes par lots ne passent qu'après la fermeture des formulaires par les collègues.
• Les utilisateurs reçoivent des conflits d'écriture et les résolvent en copiant le texte à part ou en rouvrant les enregistrements.
• Compacter et réparer est devenu une opération d'entretien régulière au lieu d'une reprise exceptionnelle.

Une base divisée, avec un fichier frontal par utilisateur et des tables dorsales partagées, est généralement plus sûre qu'un seul fichier partagé contenant tout. Elle reste une base sur fichiers à travers le réseau. Elle n'acquiert ni transactions côté serveur, ni contrôle central des connexions, ni déploiement indépendant de la logique métier. Considérez la division comme une mesure de confinement lorsqu'elle réduit la contention immédiate, pas automatiquement comme l'architecture finale.

Les sauvegardes ne prouvent pas la capacité de reprise

Copier le classeur ou la base est nécessaire, mais une copie réussie ne prouve pas que le processus peut reprendre. La récupération exige le bon ensemble de fichiers, un point d'exécution cohérent, des connexions externes et des identifiants qui fonctionnent, les dépendances du poste et un opérateur qui sait utiliser les données restaurées.

La copie d'un dorsal Access actif pendant les écritures peut ne pas représenter un point métier propre. Un classeur restauré sans ses fichiers de référence peut s'ouvrir avec des valeurs en cache qui semblent plausibles. Un classeur à macros peut dépendre d'un emplacement approuvé, d'un composant signé ou d'un complément absent. Sauvegardez le contexte d'exploitation, pas seulement le fichier visible.

Testez la reprise dans un environnement jetable. Restaurez les fichiers, déconnectez les partages d'origine et demandez à une autre personne que le responsable habituel d'exécuter un cycle représentatif. Elle doit pouvoir indiquer les entrées utilisées, comment elle a reconnu la fin et où sont parties les sorties. Comparez les totaux métier, pas seulement l'ouverture du fichier.

Définissez les points de reprise autour des transitions métier. Pour la clôture, des points utiles peuvent être le gel des entrées, la fin de l'importation, l'approbation des ajustements, l'exportation de l'écriture et la confirmation de la comptabilisation. À chaque point, listez l'état reconstructible et celui qui doit être conservé. Si une macro échoue après avoir produit la moitié d'un fichier, l'opérateur doit savoir si une nouvelle exécution duplique les lignes, les remplace ou reprend. En logiciel, cette propriété s'appelle l'idempotence. La question pratique est plus simple : que se passe-t-il si nous appuyons deux fois sur le bouton ?

L'historique des versions peut corriger une modification accidentelle, mais il ne remplace pas un historique des transactions. Un classeur restauré montre le contenu des cellules. Il peut ne pas dire qui a approuvé une exception, quel fichier source a fourni un chiffre ou si l'écriture exportée a été comptabilisée. Si le processus exige ces preuves, enregistrez-les explicitement dans le nouveau système.

Un échec de clôture révèle la vraie spécification

Une clôture ratée révèle souvent que la procédure écrite couvrait le chemin idéal alors que le système de production vivait dans les exceptions. Prenons une séquence typique. La finance reçoit plusieurs exportations, les renomme avec des noms fixes, ouvre un classeur à macros, actualise les requêtes et appuie sur un bouton. La macro vide les feuilles intermédiaires, importe les lignes, calcule les correspondances, crée un onglet d'exceptions et exporte une écriture.

À mi-chemin, une source contient un nouveau centre de coûts. Une recherche renvoie #N/A, mais un gestionnaire d'erreur continue. Le total de l'écriture est trop faible. L'opérateur le remarque grâce à un total de contrôle, ajoute la correspondance dans une feuille cachée, recalcule, supprime l'exportation partielle et recommence. La seconde exécution réussit parce que l'opérateur sait quels artefacts la première a laissés.

Une réécriture littérale de la macro conserverait la partie dangereuse : poursuivre après une correspondance inconnue. Un entretien superficiel sur les besoins pourrait rater la table cachée et l'étape de suppression. La bonne spécification sépare les étapes et rend leurs contrats visibles. L'importation doit conserver la source et déclarer les nombres de lignes. La validation doit refuser les centres de coûts inconnus avant la construction de l'écriture. Les changements de correspondance ont besoin d'un responsable et d'une date d'effet. L'exportation doit utiliser un identifiant d'exécution et refuser un doublon accidentel.

Consignez cet échec dans un tableau d'observations, pas dans un schéma de processus poli. Pour chaque étape, notez la condition préalable, l'empreinte d'entrée, le nombre de lignes, le total de contrôle, l'empreinte de sortie et l'état. Un hachage SHA-256 permet d'identifier exactement un fichier d'entrée sans stocker une copie supplémentaire dans le journal. Conservez le fichier lui-même selon les règles de rétention applicables à ses données.

L'échec révèle aussi une distinction importante : reproduire la sortie ne signifie pas reproduire le comportement. Deux implémentations peuvent produire la même écriture avec des entrées normales tout en divergeant sur les fichiers en double, les correspondances absentes, les dates autour de minuit, les cellules vides, l'arrondi décimal ou une reprise après interruption. Les tests de migration doivent couvrir ces cas limites, car les opérateurs dépendent déjà de la manière dont l'ancien système les traite, même lorsque ce comportement est gênant.

Tracez le périmètre autour des décisions

Le meilleur périmètre de migration suit les décisions métier et la propriété de l'état, pas les onglets ni les formulaires Access. Un onglet est une unité de présentation. Une requête est une unité d'implémentation. Aucun des deux ne correspond forcément à un service, une table ou un écran. Partez de décisions telles que l'éligibilité d'une facture, le compte qui reçoit un montant, le droit d'un dossier à progresser et la personne autorisée à déroger à une exception.

Pour chaque décision, nommez ses entrées, sa règle, sa sortie, son responsable et son besoin d'historique. Si une règle change selon sa date d'effet, stockez ses versions au lieu de remplacer une formule. Si des utilisateurs peuvent y déroger, conservez le motif, l'acteur, l'horodatage, l'ancienne valeur et la nouvelle. Si deux utilisateurs peuvent modifier le même dossier, définissez une concurrence optimiste avec contrôle de version ou sérialisez la transition. Ne laissez pas le comportement par défaut de la base prendre par accident une décision métier.

Gardez Excel là où il reste réellement utile. Les analystes peuvent encore avoir besoin d'une exportation pour une analyse ponctuelle, une modélisation de scénario ou une feuille de validation familière. La frontière de production change lorsque l'état faisant autorité et les règles passent dans une application et une base contrôlées. Un classeur exporté peut rester une vue sans demeurer l'unique copie de travail.

Ne reconstruisez pas non plus chaque formulaire Access pixel par pixel. Demandez quelle tâche il termine, quelle validation il applique, quels enregistrements associés il affiche et quel parcours clavier les utilisateurs expérimentés attendent. Préservez l'efficacité du travail, pas une géométrie d'écran arbitraire. Un client web peut être pire qu'Access s'il transforme une saisie rapide en trajets répétés à la souris et en boîtes de dialogue modales.

Une cible pratique pour ce type de système comprend une application serveur propriétaire des règles et transactions, une base relationnelle propriétaire de l'état, un client conçu autour des tâches et des traitements explicites d'importation et d'exportation. Go ou TypeScript peuvent gérer les services, TypeScript le client, et Postgres les contraintes et la concurrence. Le choix des langages compte moins que la visibilité de la responsabilité et du comportement en cas d'échec.

Migrez une responsabilité risquée à la fois

Une migration contrôlée retire une responsabilité après l'autre tout en gardant l'ancien système disponible pour la comparaison. Une réécriture en bascule unique concentre la découverte, l'implémentation, la conversion des données, la formation et la mise en service dans un seul événement. Elle accumule l'incertitude au moment où le retour arrière est le plus difficile.

Commencez par la responsabilité qui produit des preuves ou réduit un risque irréversible. Vous pouvez placer un service d'admission immuable devant les imports de feuilles, déplacer les tables Access vers Postgres tout en conservant temporairement le frontal, ou remplacer la macro d'exportation de l'écriture en laissant d'abord le calcul en place. Le choix dépend de l'emplacement du dommage et de ce que vous pouvez comparer.

Ne confondez pas le déplacement des données Access avec une migration terminée. Lier des formulaires Access à des tables serveur peut stabiliser le stockage et exposer les problèmes de concurrence, ce qui peut constituer une étape intermédiaire utile. Les règles métier peuvent rester dans les événements de formulaire, les modules VBA, les requêtes enregistrées et les habitudes des opérateurs. Suivez chaque responsabilité pour que le pont temporaire ne devienne pas le système final non documenté.

La migration des données a besoin de règles de rapprochement avant le premier chargement. Décidez du traitement des identifiants en double, du vide face à null, des dates sans fuseau, des nombres flottants, des pièces jointes, des champs de recherche, des enregistrements supprimés et des lignes qui violent les nouvelles contraintes. Placez les exceptions en quarantaine avec une raison. Les nettoyer sans trace donne une base propre en apparence, mais rompt son lien avec le dossier métier.

Exécutez autant que possible les anciens et nouveaux parcours sur des entrées gelées. Ne demandez pas aux utilisateurs de saisir deux fois la même transaction réelle, car cela crée deux sources concurrentes. Dupliquez les entrées, rejouez des actions enregistrées ou comparez les sorties dans une fenêtre contrôlée. Rendez le retour concret : nommez l'autorité de bascule, le dernier point réversible, les données à rejouer et les conditions qui déclenchent le retour.

CodeHero prend en charge les sources Excel et Access et les réécrit en Go, Rust, TypeScript et Postgres, avec une livraison en moins de 30 jours. Cette promesse n'a de sens que si le travail inclut les fichiers environnants, les règles cachées et la séquence opérateur. Convertir seulement le VBA visible laisserait le système de production en place.

La parité doit tester le sens, pas l'écran

Un banc de parité doit envoyer les mêmes entrées enregistrées dans les deux systèmes et comparer les résultats métier normalisés. Comparer des captures d'écran prouve peu lorsque les largeurs de colonne, le tri ou le formatage changent. Le simple nombre de lignes manque aussi les comptes inversés, les arrondis différents et les exceptions absentes.

Construisez un corpus à partir de formes réelles de production après suppression ou protection des données sensibles. Incluez les exécutions normales, les dates limites, les entrées vides, les fichiers en double, les correspondances manquantes, les modifications concurrentes, les nouvelles exécutions et les interruptions. Définissez pour chaque cas les différences importantes. Un rapport non ordonné peut tolérer un autre ordre des lignes. Une écriture ne peut tolérer un compte ou un montant modifié. Un horodatage peut accepter une marge, tandis qu'une identité d'approbation doit correspondre exactement.

Une requête de comparaison utile regroupe les résultats au niveau validé par la finance. Les colonnes exactes changeront, mais la forme doit rester familière :

select account_code, currency,
       count(*) as line_count,
       round(sum(amount), 2) as total_amount
from journal_lines
where run_id = :run_id
group by account_code, currency
order by account_code, currency;

Exécutez l'extraction équivalente sur l'ancienne sortie et comparez des valeurs typées. Préservez les zéros initiaux des codes, distinguez le vide de zéro, normalisez les dates volontairement et énoncez la règle d'arrondi. Lorsqu'un résultat diffère, classez la cause comme défaut d'extraction, particularité ancienne comprise, défaut de la nouvelle implémentation ou changement de comportement approuvé. Ne modifiez pas silencieusement le résultat attendu pour faire passer le test.

Le trafic de production enregistré apporte des preuves plus fortes que des exemples choisis à la main, car il contient des combinaisons oubliées dans la spécification. Il exige quand même une revue. Le trafic historique peut omettre les rares événements annuels, les exécutions en échec ou les actions évitées par les utilisateurs à cause des limites du système. Ajoutez des cas tirés des comptes rendus d'incident, des entretiens avec les opérateurs et des processus liés au calendrier.

La parité ne donne pas l'obligation de garder tous les défauts. Elle permet un choix contrôlé. Si l'ancien classeur arrondit chaque ligne et le nouveau service seulement le total, exposez la différence, mesurez les enregistrements concernés dans le corpus et laissez le responsable métier choisir. Une différence inexpliquée bloque la bascule. Un changement approuvé devient une exigence versionnée.

La bascule réussit si les opérateurs peuvent la contester

Les personnes qui exécutent le fichier doivent pouvoir prouver que le remplacement a tort avant qu'il ne fasse autorité. Donnez-leur des sorties rapprochables, des exceptions inspectables et un moyen d'arrêter la bascule. Une formation limitée au chemin idéal transforme les opérateurs expérimentés en destinataires passifs et gaspille les connaissances qui maintenaient l'ancien système.

Utilisez des critères d'acceptation opérationnels. Le nouveau système est prêt lorsqu'un opérateur désigné peut effectuer le processus depuis l'arrivée de la source jusqu'à la sortie acceptée, reprendre une étape en échec, expliquer chaque rejet et rapprocher les totaux sans consulter la mémoire de l'ancien auteur. L'assistance a besoin d'identifiants d'exécution, de l'état des étapes, d'empreintes d'entrée, du détail des erreurs et d'une action sûre pour recommencer. La direction a besoin d'un responsable clair pour les changements de règles et les accès.

Planifiez le basculement final selon l'horloge métier. Gelez les changements de macros, requêtes, formulaires et correspondances avant la fenêtre de comparaison. Consignez précisément les anciennes versions. Décidez du sort des transactions reçues pendant la bascule et de leur rejeu. Conservez l'ancien environnement en lecture seule pendant la période de preuve convenue, mais retirez-lui le pouvoir de produire de nouvelles sorties officielles. Deux systèmes accessibles en écriture créent des litiges, pas de la redondance.

Ne mesurez pas l'adoption au silence des utilisateurs. Observez s'ils construisent des classeurs parallèles pour récupérer des filtres, exportations ou vues d'exception absents. Une nouvelle feuille à la périphérie peut être un outil d'analyse raisonnable ou le premier signe d'une fuite de la logique officielle. Examinez sa raison avant de l'interdire.

Excel et Access peuvent porter la production pendant des années parce que des personnes compétentes fournissent les contrôles qui manquent aux outils. Une migration sûre rend ces contrôles exécutables, vérifiables et récupérables. L'artefact décisif n'est pas un code plus propre. C'est une clôture, une comptabilisation, une expédition ou une approbation qui termine à l'heure, tandis que les responsables voient exactement ce qui s'est passé et peuvent arrêter le processus en cas d'erreur.