WIN TO LUX : ce que coûte vraiment une sortie de Windows

Une proposition de migration Windows vers Linux tient souvent en un tableau : nombre de serveurs, nombre de postes, licences économisées, durée. Le tableau est juste. Il est aussi la partie la moins déterminante du dossier, parce qu'il ne chiffre que ce qui se compte sans enquête.

Les trois postes qui font basculer un projet demandent tous une inspection du système existant. C'est précisément pour cela qu'ils manquent aux propositions rédigées vite.

Premier poste : la reprise des identités

Active Directory n'est pas un annuaire, c'est le point de rendez-vous de vingt ans de décisions. Stratégies de groupe, ouverture de session sur les postes, authentification intégrée des applications internes, comptes de service, délégations, unités d'organisation qui reflètent un organigramme dissous depuis longtemps.

Le remplacement par FreeIPA ou un annuaire LDAP est techniquement documenté et ne pose pas de problème de principe. Ce qui coûte, c'est l'archéologie : identifier ce qui dépend de quoi, et ce qui peut être abandonné. Dans la plupart des parcs, une partie notable des objets ne sert plus, mais personne ne peut l'affirmer sans mesure — et personne ne veut être celui qui coupe le mauvais compte de service.

La migration d'annuaire n'est pas un projet technique. C'est un projet d'inventaire dont la partie technique est courte.

Deuxième poste : la dépendance applicative

Le poste le plus imprévisible. Il se divise en trois familles, et le coût réel dépend de la répartition entre elles :

• Ce qui traverse sans effort. Applications web, bases de données courantes, outils déjà multiplateformes. C'est en général la majorité, et c'est ce que les propositions mettent en avant.
• Ce qui traverse avec une couche. Compatibilité, conteneurisation, ou machine virtuelle Windows résiduelle. Cela fonctionne, mais chaque couche ajoutée est une dette d'exploitation permanente, pas un coût ponctuel.
• Ce qui ne traverse pas. Un progiciel métier sans équivalent, un pilote propriétaire, un logiciel dont l'éditeur a disparu. Il faut alors remplacer, réécrire, ou garder une enclave Windows — et l'assumer dans l'architecture cible plutôt que de la découvrir en fin de projet.

Le rapport entre ces trois familles ne s'estime pas depuis un tableau. Il se mesure sur le parc réel, et c'est le premier travail à faire, avant tout chiffrage.

Troisième poste : la formation et l'exploitation

Celui-ci est presque toujours absent des propositions, alors qu'il court sur des années. Une équipe qui exploite du Windows depuis quinze ans a des réflexes, des scripts et un outillage qui ne se transposent pas. Pendant la période d'apprentissage, les incidents durent plus longtemps — non par incompétence, mais parce que le diagnostic est plus lent sur un système que l'on connaît moins.

Il existe deux façons de traiter ce poste. On le budgète, en formation et en accompagnement sur les premiers mois d'exploitation. Ou on ne le budgète pas, et il apparaît quand même, sous forme de temps d'indisponibilité et d'épuisement de l'équipe. La seconde option est plus chère, et elle est la plus fréquente.

Ce que nous chiffrons, et dans quel ordre

L'évaluation précède la migration, et elle se vend séparément. Elle produit l'inventaire des dépendances, la répartition réelle entre les trois familles applicatives, l'état de l'annuaire, et la cible d'exploitation. Ce n'est qu'à partir de là qu'un chiffrage veut dire quelque chose — et il arrive que sa conclusion soit de ne pas migrer, ou de ne migrer qu'une partie du parc.

Nous préférons rendre cette conclusion à l'étape de l'évaluation plutôt qu'au milieu d'un projet de migration. C'est moins vendeur et beaucoup moins cher pour vous.

Publié le 2026-07-27 · Revenir aux perspectives