LiNote · Audit · Terraform · Salt
LiNote : reprendre la maîtrise de l’infrastructure
Audit, sécurisation, correction de Salt et automatisation avec Terraform : j’ai accompagné LiNote pour retrouver des déploiements reproductibles et préparer les mises à niveau de son infrastructure.
Remettre l’infrastructure au service du produit
LiNote facilite les échanges entre les personnes âgées et leurs proches, avec des appels vidéo, des messages et des rappels accessibles sans manipulations compliquées. Derrière cette simplicité d’usage, l’équipe doit pouvoir maintenir et faire évoluer les services techniques.
Ma mission a commencé par un audit de l’infrastructure. Elle s’est poursuivie par la sécurisation du socle, la remise en fonctionnement de l’automatisation Salt et la construction d’un parcours de déploiement plus reproductible. L’objectif était de repartir de l’existant, de corriger ce qui empêchait les changements et de rendre les mises à niveau plus maîtrisables.
Auditer, prioriser, puis corriger
Avant d’ajouter de nouveaux outils, il fallait comprendre l’état du parc, les règles d’accès, les configurations système et le fonctionnement de Salt. L’audit a permis de mettre les sujets dans l’ordre : sécurisation, corrections de l’automatisation et préparation des évolutions.
La suite du travail s’est appuyée sur ce diagnostic. J’ai repris les configurations communes et corrigé les states Salt qui empêchaient une application cohérente : erreurs de rendu, identifiants en conflit, dépendances mal ordonnées et différences entre les composants.
Le but n’était pas de contourner chaque erreur au moment du déploiement, mais de réparer les mécanismes qui devaient servir aux interventions suivantes.
De l’audit aux mesures concrètes
Sécuriser l’infrastructure après l’audit
Après le diagnostic, j’ai mis en œuvre un chantier de sécurisation du socle existant. Les priorités de l’audit ont été traduites en règles d’administration, de filtrage et de protection, regroupées dans une configuration commune gérée par Salt.
Ce travail avait un objectif distinct de la réparation des déploiements : mieux maîtriser les accès et les échanges entre services, tout en rendant les règles de sécurité plus simples à maintenir.
- Maîtriser les accès d’administration
- Reprise des configurations SSH et de l’administration des systèmes, avec des règles communes plutôt que des réglages indépendants sur chaque machine. Ces choix sont décrits dans le code pour pouvoir être relus et appliqués de façon cohérente.
- Encadrer les échanges réseau
- Centralisation des règles de filtrage et adaptation aux rôles des machines et aux environnements. L’objectif est de limiter les flux aux besoins des services, en conservant les communications nécessaires à leur fonctionnement.
- Renforcer la protection et la traçabilité
- Intégration de mécanismes de protection contre les tentatives d’accès abusives et d’audit des événements système dans le socle commun. Ces éléments complètent le travail sur les accès et le filtrage.
Appliquer les corrections sans perdre la maîtrise des changements
Les configurations ont été préparées en laboratoire, puis déployées progressivement avec des contrôles et des procédures de retour arrière. La sécurisation s’inscrit ainsi dans la même discipline que les évolutions applicatives : préparer, vérifier et appliquer par étapes.
Pour l’équipe LiNote : un socle de sécurité homogénéisé, dont les règles sont intégrées à l’automatisation. Les opérations de maintenance et les prochains déploiements peuvent reprendre cette base, au lieu de reconstituer les réglages machine par machine.
Les contraintes de la mission
Intervenir sur un service existant
Les corrections devaient tenir compte des applications et des dépendances déjà en place. Le travail a été préparé sur des environnements de test, puis appliqué progressivement, avec des contrôles et des possibilités de retour arrière.
Reprendre Salt sans tout remplacer
La base d’automatisation existait. Il fallait en corriger les bugs, clarifier l’organisation et retrouver un ordre d’application fiable, plutôt que repartir sur une autre stack et abandonner le travail déjà réalisé.
Préparer la maintenance
Les mises à niveau devaient devenir des opérations que l’on peut préparer, tester et rejouer. La configuration commune, les étapes applicatives et les procédures d’exploitation ont été traitées ensemble.
Une architecture Salt remise en cohérence
J’ai réorganisé le socle commun et les rôles applicatifs pour rendre leurs responsabilités plus claires. Les configurations système, les services, les dépendances et les actions de déploiement doivent s’appliquer dans un ordre compréhensible, sans dépendre de corrections manuelles ajoutées après coup.
Les interventions ont couvert les dépendances entre utilisateurs, groupes et services, les chemins applicatifs, les migrations et les incompatibilités rencontrées lors des changements d’environnement d’exécution. Le démarrage et le rechargement des services ont également été remis en cohérence avec les changements de configuration.
Le socle de sécurité a été regroupé dans des règles communes, adaptées aux rôles des machines : administration, accès, filtrage et suivi système. Cette organisation permet de maintenir la configuration dans Salt plutôt que de gérer chaque serveur comme une exception.
Construire le staging avec l’IaC
Le staging a été décrit avec Terraform pour créer les ressources nécessaires à la préparation des changements. cloud-init assure la préparation initiale des machines ; Ansible orchestre le raccordement des composants ; Salt applique les configurations et les déploiements.
Une partie importante du travail a consisté à fiabiliser cet enchaînement. Les informations nécessaires aux dépendances doivent être disponibles avant l’application des states concernés. Le raccordement et l’ordre d’exécution ont donc été explicités plutôt que laissés à plusieurs tentatives manuelles.
En production, Terraform a été utilisé sur le périmètre concerné par le nouveau CRM, en s’appuyant sur l’infrastructure existante. La mission ne consistait pas à reconstruire toute la production : le périmètre de chaque outil suit le besoin réel.
Des upgrades préparés, automatisés et livrés
Les mises à niveau ont porté sur les environnements d’exécution et les composants applicatifs concernés, notamment le backend, les workers et le CRM. Les dépendances ont été ajustées, les opérations de migration intégrées et les redémarrages rendus explicites dans le déroulement du déploiement.
Pour le CRM, le travail a inclus la préparation d’une nouvelle cible système, son déploiement par Terraform puis sa configuration avec Salt. Les changements ont été préparés et vérifiés en staging avant la mise en production.
Les upgrades backend/workers et le nouveau CRM sont livrés et validés en production. L’équipe dispose désormais d’une base d’automatisation utilisable pour préparer les prochaines évolutions, avec les étapes et les contrôles associés.
Les livrables que l’équipe récupère
- Un rapport d’audit et un plan d’action, pour relier les corrections aux besoins de l’infrastructure.
- Le socle de sécurité administré par Salt, avec les règles communes d’accès, de filtrage, de protection et de suivi système.
- Le code Salt corrigé et réorganisé, avec un socle commun et des rôles applicatifs plus cohérents.
- Les configurations Terraform du staging et du périmètre de production pris en charge.
- Les fichiers cloud-init et l’orchestration Ansible, pour préparer les machines et enchaîner les opérations.
- Un laboratoire et des procédures de validation, pour préparer les changements avant leur application à l’existant.
- Des procédures d’upgrade, de déploiement et de retour arrière, ainsi qu’un historique des corrections techniques.
Ce que cela change pour LiNote
Des déploiements reproductibles
Les environnements concernés peuvent être construits ou redéployés à partir de l’IaC. Les paramètres et l’ordre des opérations sont explicités, au lieu de dépendre d’une suite de gestes à reconstituer.
Des upgrades maîtrisés
Les mises à niveau s’appuient sur des mécanismes automatisés et des procédures de test et de retour arrière. Le travail préparé pour une évolution devient une base pour les suivantes.
Un socle plus cohérent
Salt est remis en fonctionnement, les configurations de sécurité sont homogénéisées et les responsabilités des composants sont clarifiées. La maintenance peut reprendre ce socle commun plutôt que multiplier les exceptions.
Investir dans ce qui pourra être réutilisé
L’intérêt de cette intervention tient à la continuité entre audit, corrections et automatisation. L’audit donne les priorités ; les corrections rendent le socle exploitable ; l’IaC permet de reprendre le travail lors des déploiements et des upgrades.
Pour l’équipe, cela signifie moins de dépendance aux manipulations ponctuelles et une meilleure compréhension des opérations à effectuer. Le code et les procédures constituent un point de départ concret pour poursuivre la maintenance et faire évoluer l’infrastructure.
Votre automatisation ne suit plus l’évolution de votre infrastructure ?
Parlons des opérations qui bloquent, des mises à niveau à préparer et du socle à remettre en état avec votre équipe.