Chapitre 5 / 39

Le principe de la boîte noire Sodiwin

Une règle prime sur toutes les autres décisions de ce manuel : Sodiwin est une boîte noire. Chaque système en aval lit depuis un export CSV daté sur le Synology. Pas de pilote ODBC en production, pas de JDBC depuis un Worker, pas de requête sur la base Pervasive en direct depuis la couche MCP. Si vous écrivez du code qui touche Sodiwin, vous écrivez du code qui lit des CSVs.

Cette règle existe pour quatre raisons, chacune suffisante à elle seule.

Premièrement, le schéma est opaque. Sodiwin tourne sur Pervasive SQL avec un schéma entièrement interne au fournisseur. Une reconnaissance initiale n’a trouvé aucune correspondance pour les noms de tables Sodiwin en dehors de la base clients du fournisseur — les définitions de tables sont internes au fournisseur et peuvent changer sans préavis. Dépendre d’un schéma que vous ne pouvez pas lire est une façon garantie de perdre une semaine sur un renommage silencieux.

Deuxièmement, l’ERP est critique pour l’activité. Chaque commande, chaque facture, chaque mouvement de stock passe par Sodiwin. Paul est l’administrateur de l’ERP. Rani, l’équipe entrepôt et le reste du personnel terrain l’utilisent tous les jours. Un outil MCP expérimental qui maintient une connexion directe et envoie une longue requête au mauvais moment peut provoquer une dégradation des opérations. La règle de la boîte noire élimine entièrement ce risque.

Troisièmement, le contrat est plus propre. Traiter Sodiwin comme une boîte noire impose un contrat de données écrit avec Florian plutôt qu’une dépendance à la connaissance du schéma interne. Le contrat : ces 21 fichiers, ce format, ce calendrier, ce mode de défaillance. Quand Florian livre un changement de schéma, il livre une nouvelle colonne, pas une surprise — et quand Sodimo demande un nouveau champ, la demande est spécifique et actionnable.

Quatrièmement, l’artefact est durable. Les exports CSV datés sont la propriété de Sodimo. Ils survivent à tout changement côté fournisseur, à toute mise à jour, à toute migration. Si Sodimo change un jour de système backend, le registre historique reste — parce qu’il vit dans /volume1/sodiwin-dumps/, pas dans une base de données propriétaire.

La règle a trois corollaires qu’un futur ingénieur doit intégrer. Premièrement, si vous avez besoin d’une nouvelle colonne, vous le demandez à Florian ; vous ne faites pas d’ingénierie inverse sur le schéma Pervasive. Deuxièmement, si vous pensez avoir besoin de données en temps réel, réfléchissez à si le rythme nocturne est suffisant — c’est presque toujours le cas. Troisièmement, si vous avez absolument besoin de lire des données en direct, vous écrivez le code d’accès sur la machine Framework et vous le protégez derrière des chemins Tailscale admin-only ; il ne touche jamais la surface des tokens bearer MCP.

Un chemin d’escalade existe dans les runbooks internes si le canal Florian venait à se rompre — un chemin d’extraction natif Pervasive en dernier recours, plus quelques contacts de support. Rien de tout cela ne devrait être nécessaire. La règle de la boîte noire, correctement appliquée, évite à Sodimo de se retrouver dans cette situation.