Les mises à jour de firmware sur un parc de serveurs semblent être une opération de routine, jusqu'à ce que le nombre de serveurs dépasse 50 ou 100. À partir de cette échelle, ce n'est plus la connaissance du risque, mais l'effort manuel requis qui détermine si une faille de sécurité connue reste ouverte.
À partir d’environ 50 serveurs, les mises à jour du firmware nécessitent un processus dédié : inventaire de toutes les versions, groupe de test comprenant du matériel représentatif, plage horaire de maintenance fixe et un plan de retour en arrière préparé. Redfish uniformise l'interface de mise à jour pour tous les fabricants, mais ne remplace pas la vérification visant à déterminer quelle version convient à quel type de serveur.
Pourquoi les mises à jour manuelles du firmware ont leurs limites
HPE explique clairement la différence. L'intégration manuelle de plus de 100 serveurs prend des heures, voire des jours, tandis que cette même tâche peut être réduite à une seule commande grâce à l'automatisation en masse d'iLOrest (HPE, 2026). C'est précisément entre ces deux chiffres que réside la raison pour laquelle la gestion des mises à jour du firmware dans les parcs de serveurs en pleine expansion nécessite un processus planifié.
La mise à jour d'un seul serveur est rapide. Il suffit de se connecter à l'interface d'administration, de télécharger le nouveau fichier de micrologiciel, de lancer la procédure, d'attendre, puis de vérifier le résultat. Avec dix serveurs, on peut encore répéter cette opération manuellement. Mais avec une centaine, voire plusieurs centaines de serveurs, cette tâche routinière devient un véritable projet à temps plein, dans lequel chaque étape manuelle constitue une source d'erreur supplémentaire.
par an et par site, tel est le montant que peuvent atteindre les coûts de truck roll, c'est-à-dire les coûts liés à l'intervention physique de techniciens sur place lorsqu'aucun accès à distance n'est en place.
Vertiv, 2022
Redfish comme langage commun pour les mises à jour du micrologiciel
Pour que l'automatisation fonctionne entre différents fabricants, il faut une interface commune. La norme DMTF Redfish standardise les services de mise à jour du micrologiciel depuis la version 2016.2, utilisables via la même structure d'API chez tous les fabricants qui la prennent en charge. Quiconque exploite une flotte hétérogène en profite directement. Au lieu de gérer un script de mise à jour propre à chaque fabricant, une grande partie de la logique peut passer par une interface commune. La façon dont s'effectue le passage depuis IPMI est décrite dans l'article consacré à la Migration IPMI vers Redfish.
Cela réduit la charge de maintenance liée à l'automatisation, mais ne remplace pas la planification du contenu. Chaque fabricant publie ses mises à jour de micrologiciel à son propre rythme, avec ses propres notes de mise à jour et ses propres problèmes connus. Une interface commune ne signifie pas que chaque version de micrologiciel soit automatiquement adaptée à chaque type de serveur.
Orchestration des mises à jour sur de longues distances
Dans le cas de sites répartis sur de longues distances, une question technique supplémentaire se pose. Quel est le volume réel de trafic de données transitant par le réseau étendu lors d’une mise à jour ? SynergyCP, par exemple, orchestre le provisionnement via le WAN de manière à ce que le trafic de données proprement dit reste au niveau local, tandis que seules les commandes de contrôle transitent par l’instance centrale (SynergyCP, 2026). Pour les fichiers de micrologiciel, qui peuvent atteindre plusieurs centaines de mégaoctets selon la génération de serveur, cette différence est déterminante lorsque la connexion du site est limitée.
Le processus, de l'inventaire au retour en arrière
| Étape | Sommaire | Ce qui se passe sans elle |
|---|---|---|
| Inventaire | Version, génération matérielle et usage prévu pour chaque serveur | On ne sait pas quels systèmes sont encore concernés par une faille connue |
| Groupe de staging | tester d'abord un petit sous-ensemble représentatif | Une erreur affecte immédiatement l'ensemble de la flotte |
| Déploiement progressif | Groupe par groupe plutôt que d'un seul coup | Impossible de faire un arrêt en cas d'anomalies |
| Plan de retour en arrière | Version précédente disponible, procédure documentée via le BMC | Une mise à jour ratée entraîne une interruption prolongée |
Sans cet inventaire, il est impossible de définir des priorités ni de déterminer quels systèmes sont encore concernés par un problème de sécurité connu. Le groupe de préparation doit en effet couvrir toutes les variantes matérielles présentes dans le parc, et pas seulement les modèles les plus récents. Une fenêtre de maintenance fixe en fait tout autant partie que le plan de restauration.
Lire la version du micrologiciel pour l'ensemble de la flotteNous fournissons l'inventaire de l'ensemble des sites ainsi qu'une proposition concernant les groupes de préparation et l'ordre de déploiement.
Pourquoi la vue d'ensemble fait toute la différence
Quiconque garde une flotte de serveurs sous contrôle centralisé via KVM Fleet dispose, en cas de panne, d'un accès direct à la console pour repérer rapidement les cas isolés et les traiter de manière ciblée. La façon dont cette même vue centralisée peut aussi servir à l'accès KVM-over-IP quotidien sur plusieurs sites est décrite dans l'article consacré au KVM sur IP à l'échelle d'un parc informatique. La raison pour laquelle la maintenance du micrologiciel est en même temps un sujet de sécurité est exposée dans l'article consacré à la Sécurité BMC.
Foire aux questions
Les mises à jour du micrologiciel peuvent-elles être effectuées pendant le fonctionnement ?
De nombreuses mises à jour de firmware nécessitent un redémarrage du serveur ou, à tout le moins, une brève interruption du composant concerné. Dans le cas de systèmes redondants, il est possible de retirer un serveur du réseau actif, tandis que les autres prennent le relais. Pour les serveurs individuels sans redondance, une fenêtre de maintenance planifiée est généralement inévitable.
Comment tester au préalable une mise à jour du micrologiciel sans mettre en péril l'ensemble de la flotte ?
La procédure habituelle consiste à constituer un petit groupe de test doté d'un parc informatique représentatif. Ce groupe reçoit la mise à jour en premier et est soumis à une période d'observation définie avant que le reste du parc ne suive. Il est important que ce groupe de test couvre effectivement toutes les variantes de matériel présentes dans le parc.
Que faire en cas d'échec d'une mise à jour du micrologiciel ?
Un plan de restauration préparé à l'avance fait ici la différence entre un incident de courte durée et une panne prolongée. Cela implique notamment de disposer de la version précédente du micrologiciel, ainsi que d'une procédure documentée permettant d'accéder au serveur concerné via le BMC et de le réinitialiser, même si le système ne démarre plus.
La prochaine étape
torck déploie lui aussi les mises à jour de micrologiciel pour sa propre flotte de serveurs via KVM Fleet, avec un groupe de staging et un plan de retour en arrière comme décrit dans cet article. L'équipe de Maxhütte-Haidhof, Vienne et Rabat connaît les sources d'erreur par sa propre pratique. Pour en savoir plus, rendez-vous sur la Page produit.
German 
English 
French