Configurer quelques laptops pour une équipe est censé être une opération simple. En théorie, tout est déjà prévu, documenté, industrialisé. En pratique, dès que l’on cherche à faire les choses proprement, on se retrouve très vite face à des solutions pensées pour des organisations bien plus grandes que la sienne. Licences empilées, consoles cloud tentaculaires, dépendance forte à un écosystème unique, et une facture qui grimpe sans toujours correspondre à la réalité du besoin.
Je me suis retrouvé exactement dans cette situation. Pas une DSI, pas un parc de cent machines, mais quelques laptops à préparer, maintenir et sécuriser dans le temps. La question que je me suis posée était pourtant assez basique. Pour moins de dix machines, est il réellement nécessaire de reproduire une architecture conçue pour des dizaines ou des centaines de postes. Après plusieurs essais, quelques détours, et surtout beaucoup de recul, la réponse s’est imposée d’elle même.
Je ne remets absolument pas en cause les outils de Microsoft. Intune, Azure AD ou Autopilot sont solides, cohérents, et très efficaces dans leur cadre naturel. Je les ai utilisés, je comprends pourquoi ils existent, et je vois parfaitement leur intérêt dans des environnements plus larges. Le problème n’est pas leur qualité, mais leur adéquation. À petite échelle, ils apportent souvent plus de structure que nécessaire, et parfois plus de contraintes que de bénéfices concrets.
Dans mon cas, les attentes étaient volontairement limitées. Je voulais pouvoir garder la main sur les laptops, sécuriser les données sans bricolage, et rester maître de l’infrastructure. Pas dépendre d’un tenant cloud que l’on configure une fois puis que l’on subit ensuite, ni d’une console qui décide pour moi ce qui est considéré comme un usage normal. Ce n’était pas une posture anti cloud, mais simplement un besoin de compréhension et de contrôle.
Plutôt que d’ajouter une couche Microsoft supplémentaire, j’ai choisi d’assembler des briques simples, éprouvées, et surtout réversibles. MeshCentral s’est imposé assez naturellement pour la gestion et le support à distance. Naturellement sur le principe, beaucoup moins sur l’expérience. L’interface est austère, parfois franchement moche, et clairement pensée par des ingénieurs pour des ingénieurs. Rien n’est là pour séduire, et il faut accepter de travailler avec un outil qui ne cherche pas à être agréable, seulement fonctionnel.
L’installation n’a d’ailleurs pas été une promenade de santé. Sur le papier, MeshCentral est simple à déployer. Dans la réalité, l’intégrer proprement sur mon VPS, derrière mon PaaS CapRover, a demandé pas mal de tâtonnements. Gestion des certificats TLS, ports exposés, redirections, conflits entre ce que MeshCentral veut gérer lui même et ce que CapRover impose déjà. Il a fallu tester, casser, recommencer, et parfois chipoter là où on aurait préféré que ça fonctionne tout seul.
J’ai passé plus d’une soirée à jongler entre la documentation, le terminal, et ChatGPT pour générer ou corriger des commandes, ajuster des fichiers de configuration, comprendre pourquoi un certificat passait côté navigateur mais pas côté service. Rien d’insurmontable, mais clairement pas de la crème. C’est le prix à payer quand on veut rester maître de son infrastructure sans tout déléguer à une plateforme clé en main.
PowerShell m’a ensuite permis d’automatiser ce qui devait l’être, en restant dans des mécanismes natifs à Windows que je maîtrise déjà. Pour la sécurité, je n’ai rien cherché d’exotique. Windows Defender et BitLocker font déjà très bien le travail lorsqu’ils sont correctement configurés. Winget s’est chargé du reste, avec des installations propres, reproductibles, et faciles à maintenir.
Concrètement, lorsqu’un nouveau laptop arrive aujourd’hui, il n’y a presque rien à faire localement. L’agent est installé, la machine rejoint l’environnement, et je peux tout piloter à distance depuis mon Mac. Comptes, sécurisation, logiciels, mises à jour, journaux, tout est orchestré sans multiplier les clics ni naviguer dans des interfaces lourdes. Ce n’est pas spectaculaire, et ce n’est pas censé l’être. C’est simplement fonctionnel, lisible, et cohérent dans le temps.
J’aurais pu confier tout cela à un prestataire avec une solution clé en main. Beaucoup le font, et parfois à juste titre. Mais le coût n’est pas uniquement financier. Il est aussi technique et mental. On te vend de la simplicité, mais tu perds peu à peu la compréhension de ce qui se passe réellement sur tes machines. Ici, je sais exactement ce qui est fait, quand, et pourquoi. Et surtout, je sais quoi regarder quand quelque chose ne fonctionne pas comme prévu.
Il y a aussi un aspect que je n’avais pas forcément anticipé au départ. Monter ce type de mini IT soi même, c’est apprendre. C’est comprendre Windows au lieu de le subir. C’est être capable de dépanner sans ouvrir un ticket ni attendre un retour standardisé. C’est construire un système imparfait mais maîtrisé, que l’on peut expliquer, documenter, et faire évoluer sans repartir de zéro à chaque changement d’outil ou de stratégie commerciale d’un éditeur.
Évidemment, cette approche ne convient pas à tous les contextes. Dès que l’on change d’échelle, que les exigences réglementaires augmentent, ou que la gestion doit être largement déléguée, les solutions Microsoft reprennent tout leur sens. Mais pour une petite équipe, ou un indépendant qui accepte de mettre un peu les mains dedans pour garder le contrôle, cette voie est loin d’être marginale.
Elle ne cherche pas à remplacer les grandes plateformes. Elle rappelle simplement qu’il existe encore un espace entre le bricolage et l’usine à gaz. Un espace où l’IT reste compréhensible, imparfait parfois, mais profondément aligné avec les besoins réels du terrain.
Parfois, le bon choix n’est pas celui qui brille le plus dans les présentations, mais celui que l’on comprend vraiment et que l’on est capable d’assumer, même quand ça demande un peu de patience.