Le système dont dépend le fonctionnement d'une entreprise — celui qui gère les commandes, les politiques, les fichiers ou les expéditions — ne se construit pas en accumulant des fragments générés au fur et à mesure. Il nécessite un modèle de données défini, des contrats entre les modules, un modèle d'autorisations et de traçabilité ; or, ces quatre éléments sont le fruit de décisions, et non des résultats obtenus.
La confusion provient du fait que la production assistée fonctionne très bien en périphérie, ce qui crée l'attente qu'elle fonctionnera de la même manière au cœur du réseau.
Critère | Système central | Système périphérique |
|---|---|---|
Si cela cesse de fonctionner | L'entreprise pour | Quelqu'un est contrarié. |
Durée de vie utile prévue | 5-15 ans | Des mois ou quelques années |
Nombre d'intégrations | Nombreux et critiques | Peu ou pas |
Le coût d'une erreur | Argent, client ou satisfaction | Temps perdu |
Qui devrait pouvoir le soutenir ? | Toute équipe compétente | Qui a fait ça ? |
La première ligne suffit à classer les cas 90%. Si la réponse à la question « Que se passe-t-il si cela cesse de fonctionner pendant une journée ? » est que la facturation, la production ou le service client sont interrompus, alors il s'agit d'un système critique et il doit être traité comme tel, quelle que soit son importance.
Une erreur fréquente consiste à croire que le système central est l'élément le plus important. Il existe des petits systèmes dont dépend l'ensemble des opérations, et d'énormes systèmes dont l'absence, même pendant une semaine, ne se ferait sentir nulle part.
Le modèle de données. La manière dont les entités commerciales sont représentées : qu’est-ce qu’un client, un fichier, un envoi ? Quelles relations entretiennent-elles ? Quelles étapes de leur parcours ? C’est la décision la plus coûteuse à modifier, car tout le reste repose dessus.
Limites de propriété. Quel module est prioritaire sur quelles informations et quelles requêtes ? Sans cette décision, trois systèmes semblent écrire les mêmes données, et il est impossible de savoir lequel est correct.
Le modèle des permissions. Les droits d'accès et les autorisations d'action sont définis au niveau du système et non par des conditions répétées dans l'application. C'est ce qui détermine si un assistant, un portail client ou une API peut être ajouté demain sans créer de vulnérabilité.
Traçabilité. Chaque modification est enregistrée, ainsi que sa durée de conservation. Cette opération est irréversible : ce qui n’a pas été enregistré est perdu.
Aucun de ces quatre éléments ne peut être délégué à un outil de génération, car ils dépendent tous de la connaissance du secteur d'activité et de la capacité à anticiper son évolution.
Il serait absurde de renoncer à la vitesse disponible. Au sein d'un cœur bien structuré, la génération assistée est performante dans les domaines suivants :
La règle est simple : La construction est déléguée, pas la structure.. Et l'examen reste obligatoire, pour la raison que nous avons expliquée dans Le code que personne ne comprend, c'est la dette.
Il existe un critère opérationnel permettant de déterminer si un système central est bien construit, et il ne nécessite pas d'audit : Une autre équipe pourrait-elle prendre le relais de ce système en un mois, sans consulter la personne qui l'a construit ?
Pour que la réponse soit oui, quatre éléments sont nécessaires : une documentation d’architecture, des contrats d’intégration versionnés, des tests qui expriment les attentes de l’entreprise et des décisions expliquées par écrit.
Un système qui échoue à ce test représente un risque opérationnel réel, indépendamment de sa qualité technique : la continuité de l’activité de l’entreprise repose sur la disponibilité de certains personnels. Cela a également un impact financier, car c’est précisément ce qui est pénalisé lors d’un audit technologique.
Parce que les barrières à l'entrée pour produire quelque chose qui fonctionne ont considérablement diminué, et avec elles les barrières à la production de quelque chose qui fonctionne mais qui n'est pas durable.
Les données de GitClear portant sur 211 millions de lignes de code révèlent une tendance : le travail de refactorisation a chuté d'environ 251 TP3T de modifications totales en 2021 à moins de 101 TP3T en 2024, tandis que la réplication a été multipliée par huit. On construit davantage et on structure moins ; dans un système périphérique, cela reste gérable, mais dans un système central, cela représente un fardeau.
Lorsqu'il s'agit de décider comment construire un système critique, la discussion utile ne porte pas sur la méthodologie ou les outils. Elle porte sur trois engagements :
Avec ces trois compromis, la rapidité de génération est un avantage. Sans eux, c'est le moyen le plus rapide connu de construire quelque chose d'immuable.
Il s'agit du système dont dépend l'exploitation : s'il cesse de fonctionner ne serait-ce qu'une journée, la facturation, la production et le service client sont interrompus. Sa taille n'est pas un critère déterminant – il existe des systèmes centraux de petite taille et des systèmes plus importants qui ne le sont pas – mais les conséquences de son indisponibilité.
Quatrièmement : le modèle de données représentant les entités métier, les limites de propriété déterminant quel module contrôle quelles informations, le modèle d’autorisations défini comme une couche système et la traçabilité des modifications. Aucun de ces éléments ne peut être délégué à un outil de génération.
Oui, dans le cadre d'une structure prédéfinie : mise en œuvre de règles prédéfinies, couche de présentation, transformations avec critères d'acceptation explicites et documentation des cas précédemment décrits. La règle consiste à déléguer la construction, et non la structure.
Le test de transition consiste à évaluer si une autre équipe peut prendre le relais dans un délai d'un mois sans consulter l'équipe d'origine. Cela nécessite une documentation architecturale, des accords d'intégration versionnés, des tests démontrant les attentes métier et des décisions clairement expliquées.
Un risque opérationnel — la continuité dépendant de personnes spécifiques — et un risque financier, car c'est précisément ce qui est pénalisé lors d'une vérification préalable technologique pour évaluer l'entreprise ou rechercher des investissements.
Car la barrière à la production de code fonctionnel a considérablement diminué. GitClear a constaté que le refactoring est passé d'environ 251 TP3T de modifications totales en 2021 à moins de 101 TP3T en 2024, et que la duplication a été multipliée par huit : on construit davantage et on structure moins, ce qui, dans un système critique, devient un fardeau.
Allez-vous construire un système dont votre activité dépendra ? Nous définissons l'architecture, le modèle de données et les contrats avant d'écrire le code, et nous vous transférons le code et la documentation par contrat. Parlons-en → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
