Linux, open source et standards
Évaluer et réaliser des systèmes ouverts et des standards selon leur maintenabilité, leur maîtrise, leur interopérabilité et leur exploitation à long terme.
Linux, l’open source et les standards ouverts ne sont pas des fins en soi. Ils sont utiles lorsqu’ils rendent une fonction concrète plus maintenable, maîtrisable et interopérable avec d’autres systèmes. Le choix dépend des besoins, de l’existant et des personnes capables d’exploiter et de rétablir durablement la solution, et non d’une promesse générale selon laquelle une technologie ouverte serait toujours meilleure, plus sûre ou moins coûteuse.
Situations de départ typiques
- Un système Linux ou BSD remplit une fonction importante, mais il n’est que partiellement documenté ou dépend d’un savoir individuel.
- Des composants propriétaires et ouverts doivent fonctionner ensemble de manière fiable alors que les interfaces ou les responsabilités restent floues.
- Une plateforme doit être renouvelée sans remplacer inutilement une technologie existante qui remplit encore son rôle.
- Des formats, protocoles ou interfaces ouverts doivent faciliter la transmission et l’échange de données.
- Une évolution prévue manque de critères de décision, de transition progressive ou de voie de repli fiable.
- Des sauvegardes existent, mais le redémarrage, les accès et les responsabilités n’ont pas été examinés conjointement pour le périmètre concerné.
Des critères de décision plutôt qu’une position de principe
Nous évaluons les composants possibles par rapport à la fonction réellement nécessaire. Les critères comprennent la maintenabilité, la traçabilité de la configuration, les interfaces disponibles, l’interopérabilité, les connaissances d’exploitation, les voies de mise à jour, les dépendances et la durée d’usage prévue. Les licences, contrats et services externes existants peuvent également influencer la décision.
Le code source ouvert ne crée à lui seul ni exploitation sûre ni indépendance. Une solution ouverte peut être inadaptée si les fonctions nécessaires, les personnes responsables, les modalités de maintenance ou une documentation exploitable font défaut. À l’inverse, une combinaison maîtrisée de systèmes ouverts et propriétaires peut constituer la solution la plus robuste.
Analyse, planification et réalisation clairement délimitée
Analyse
Nous recensons la fonction convenue, les systèmes Linux ou BSD concernés, les applications, les réseaux, les flux de données et les interfaces. La documentation, les configurations, les sauvegardes et les responsabilités existantes sont examinées dans le périmètre approuvé. Le résultat est une base de départ traçable avec ses hypothèses, ses dépendances et les décisions ouvertes, et non un jugement général sur un produit.
Planification
Nous élaborons une structure cible et déterminons quels composants existants peuvent être conservés, quelles transitions sont nécessaires et comment protéger l’exploitation et le repli pendant l’évolution. Les lots de travaux, les conditions de vérification, les responsabilités et les transmissions sont délimités avant la réalisation. La coexistence ou une transition progressive est possible lorsqu’elle correspond à la mission et à l’environnement d’exploitation.
Réalisation clairement délimitée
Nous effectuons les travaux convenus d’installation, de configuration, d’intégration et de documentation dans le périmètre approuvé. Les changements concernant les réseaux, les applications ou les services externes sont coordonnés avec leurs responsables respectifs. L’exploitation globale, les achats, les corps de métier tiers ou les systèmes non approuvés ne deviennent pas implicitement partie de la mission.
Systèmes et standards en contexte
Les systèmes Linux et BSD peuvent servir de plateformes, de composants réseau ou d’infrastructures liées à l’exploitation. OpenWrt, VyOS, OpenBSD et OPNsense sont des exemples existants de plateformes ouvertes pour routeurs et pare-feu. Leur adéquation dépend de la fonction, des interfaces, de la maintenabilité et du transfert vers l’exploitation. Ces exemples ne sont ni complets ni exclusifs et ne constituent aucune affirmation de statut de fabricant, de partenaire ou de certification.
Les formats, protocoles et interfaces documentées et ouverts peuvent faciliter les échanges entre composants et une transmission ultérieure. Leur suffisance dans un environnement précis doit toutefois être vérifiée techniquement ; le nom d’un standard ne remplace pas une vérification de l’intégration ou du rétablissement.
Exploitation, sauvegarde, repli et rétablissement
La vision d’exploitation convenue ne couvre pas seulement les systèmes en fonctionnement. Nous considérons aussi les accès nécessaires, les sauvegardes des configurations et des données, les dépendances aux réseaux et aux services externes ainsi que les responsabilités en cas de changement ou d’incident. Les voies de repli et de rétablissement sont planifiées ou examinées au niveau permis par le périmètre, les moyens disponibles et les créneaux d’exploitation approuvés.
La documentation et les sauvegardes sont des prérequis importants, mais elles ne garantissent ni disponibilité ni rétablissement. Les vérifications pratiques ou exercices ne sont effectués que si leur périmètre, leurs risques et leurs autorisations sont expressément convenus.
Livrables possibles de documentation et de transmission
Selon la mission, les éléments suivants peuvent notamment être produits :
- un état des lieux des systèmes, fonctions, interfaces et responsabilités concernés ;
- une vue argumentée des options ou décisions ;
- une planification de la cible et de la transition avec des lots de travaux délimités ;
- des journaux de configuration, de changement et de vérification ;
- une vue des accès, sauvegardes, voies de repli et de rétablissement ;
- une documentation d’exploitation et de transmission pour le périmètre convenu.
Il s’agit de livrables de travail possibles, dépendant de la mission, et non de résultats promis de manière générale. Le contenu, le niveau de détail, la réception et la responsabilité de mise à jour sont définis pour le projet concerné.
Interfaces client et participation
L’équipe cliente désigne les responsables fonctionnels et techniques, fournit les documents existants et les accès convenus, et décrit les fonctions concernées ainsi que les risques d’exploitation acceptables. Les autorisations, créneaux de maintenance, réceptions et interventions des équipes internes ou d’autres prestataires restent clairement attribués.
Pour les interfaces et les transitions progressives, les responsables des systèmes participants doivent être disponibles. Les prérequis, droits ou décisions manquants sont consignés comme interfaces client ouvertes ; ils ne créent aucune responsabilité automatique pour les systèmes hors du périmètre convenu.
Limites et exclusions
- aucune affirmation générale selon laquelle l’open source serait plus sûr, moins coûteux ou intrinsèquement supérieur ;
- assistance et maintenance uniquement sur accord distinct ; aucune exploitation 24 h/24 et 7 j/7 incluse par défaut ;
- aucune vente de produits ou de licences et aucun modèle de revendeur ;
- aucune assistance générale pour PC, imprimantes ou petites demandes ;
- aucune migration, certification, évaluation de conformité ou garantie de sécurité incluse automatiquement ;
- aucune garantie de délai, de disponibilité, d’économie ou de résultat ;
- aucune réalisation hors du périmètre convenu ou sans les autorisations nécessaires.
La vue d’ensemble des services situe ce thème dans l’offre globale. Le conseil et la planification de projet établissent la base de décision ; les réseaux, le routage et la radio approfondissent les tâches liées aux réseaux. Nos principes pour des systèmes maîtrisables expliquent les orientations techniques.
Discuter d’un projet de systèmes ouverts
Décrivez la fonction concernée, l’environnement existant, les interfaces connues et l’évolution souhaitée. Nous pourrons alors déterminer quelle analyse, planification ou réalisation délimitée est pertinente et quels prérequis doivent être traités en premier.