01SYSTEM THINKING
Pourquoi un projet IT ne devrait pas commencer par la stack
Les choix technologiques sont importants, mais ils ne constituent pas la première décision d’architecture. Choisir base de données, framework ou modèle de déploiement avant de comprendre le processus peut conduire le projet à servir ses outils plutôt que le besoin métier.
Je commence généralement par la carte du processus et des données : qui crée l’information, où elle change, quelle est la source de vérité, quelles opérations sont critiques, ce qui peut fonctionner indépendamment et ce qui doit survivre à la panne d’un composant.
La stack devient alors une conséquence des exigences. Cela réduit les dépendances accidentelles, rend les évolutions plus prévisibles et permet d’évaluer l’architecture par les résultats : temps, coût d’exploitation, disponibilité, reprise et capacité d’évolution.
02OFFLINE-FIRST
Offline-first ne signifie pas simplement « fonctionne sans Internet »
Pour les systèmes terrain, GIS et distribués, ouvrir l’application sans connexion n’est que la partie visible. La vraie difficulté commence lorsqu’une même entité peut être modifiée dans deux répliques indépendantes.
Identifiants, versions, journal de changements, règles de synchronisation et politique de conflits doivent être conçus en amont. Il faut également permettre à l’utilisateur de comprendre pourquoi deux versions diffèrent.
Offline-first est donc une propriété du modèle de données et du cycle de vie du projet plutôt qu’un simple mode d’interface. Conçu ainsi dès le départ, le système supporte une connectivité instable sans perdre silencieusement le contrôle des données.
03PRIVATE COMMS
Infrastructure de communication privée : au-delà de l’installation du serveur
Déployer un serveur de messagerie n’est qu’une petite partie d’un système de communication d’entreprise. La production ajoute identité, clients, voix et vidéo, stockage, sauvegardes, supervision et mises à jour contrôlées.
La migration constitue un autre niveau : utilisateurs, espaces, historique et pièces jointes doivent être transférés depuis un état source figé, par lots contrôlés et vérifiés avant le basculement général.
La valeur d’une infrastructure de communication privée vient du contrôle des données et de l’exploitation. L’organisation sait où se trouve l’information, comment restaurer le service, qui gère les accès et comment la plateforme pourra évoluer.
041C / OPERATIONS
1C ne se résume pas à la configuration métier : la stabilité commence par l’infrastructure
Lorsqu’un environnement 1C devient lent ou instable, l’analyse commence souvent par la configuration applicative alors que la cause réelle peut se situer ailleurs : ressources du serveur Linux, paramètres PostgreSQL, stockage, tâches de fond, verrous, réseau ou poste utilisateur particulier.
Je considère donc un serveur 1C comme un système de production complet. Serveur applicatif, base de données, sauvegardes, journaux, mises à jour, supervision des ressources et postes clients doivent appartenir au même périmètre d’exploitation.
Cette approche commence par la mesure : identifier précisément l’endroit où apparaît la contrainte, puis modifier la bonne couche. Le support devient plus prévisible, la restauration testable et la montée en charge n’entraîne pas une succession de réglages isolés.
