Formatrice · Consultante IT indépendante · Fondatrice REC-IT & DossiMed.ai

Pour qui : toute DSI qui n'a pas testé une restauration complète depuis plus de six mois, ou qui n'a pas de référentiel à jour de ce qu'elle protège.

Le problème traité : une plateforme de sauvegarde qui tourne sans erreur visible n'est pas une plateforme qui restaure. Et l'on ne protège pas correctement ce que l'on n'a pas inventorié : sans criticité documentée, la même politique s'applique partout.

Ce que ça change : vous disposez d'un référentiel opposable de ce que vous protégez, et vous savez, preuve à l'appui, ce qui redémarrerait et ce qui ne redémarrerait pas.

Prérequis : accès en lecture à la console de sauvegarde, un interlocuteur technique, une fenêtre de test.

Pour qui : une plateforme Commvault ou Veeam qui sature, échoue ou ne tient plus ses fenêtres.

Le problème traité : performances dégradées, files de jobs qui s'accumulent, rôles concentrés sur un serveur unique, base de configuration sous-dimensionnée.

Ce que ça change : la plateforme tient de nouveau ses fenêtres, avec des chiffres pour le prouver.

Prérequis : accès administrateur, fenêtre d'intervention, référent infrastructure disponible.

Pour qui : une organisation qui doit garantir la reprise d'un système critique après sinistre, et qui doit arbitrer entre un site physique, un cloud souverain et un cloud public.

Le problème traité : un PRA écrit n'est pas un PRA. Sans matrice RTO/RPO validée par les métiers, sans architecture de réplication dimensionnée et sans plan de bascule testé, le document reste une intention — et sans comparaison chiffrée des scénarios d'hébergement, la décision d'investissement se prend à l'aveugle.

Ce que ça change : un engagement de reprise défendable devant un comité de direction ou un régulateur, et une décision d'investissement fondée sur des scénarios comparés plutôt que sur un devis unique.

Prérequis : accès à l'inventaire applicatif et aux volumétries, un interlocuteur métier pour arbitrer les RTO/RPO, les contraintes réglementaires de localisation des données.

Pour qui : une organisation qui dispose d'un PRA documenté mais ne l'a jamais éprouvé, ou dont le dernier exercice remonte à plus d'un an.

Le problème traité : le premier test réel révèle systématiquement des dépendances non documentées — un service annexe, une résolution de noms, un compte de service, un ordre de démarrage. Mieux vaut les découvrir un jour choisi qu'un jour subi.

Ce que ça change : votre PRA passe du statut de document à celui de capacité démontrée, avec une trace d'exercice opposable en audit.

Prérequis : environnement de secours disponible, fenêtre d'exercice validée, équipes infrastructure et métier mobilisées sur la durée de l'exercice.

Pour qui : un projet de déploiement, de migration ou de refonte complète de la sauvegarde, du rack à la première restauration validée.

Le problème traité : une plateforme de sauvegarde ne se juge pas à son installation logicielle mais à sa chaîne complète — un socle mal câblé ou un zonage SAN incomplet dégrade les performances bien après la mise en production, et se paie en fenêtres de sauvegarde qui débordent.

Ce que ça change : une plateforme exploitée par vos équipes, documentée et éprouvée dès la mise en service — pas dépendante d'un prestataire.

Prérequis : matériel et licences approvisionnés, accès datacenter, plages d'adressage et flux réseau ouverts, référent infrastructure disponible.

Pour qui : une DSI dont le datacenter et le site de secours ont évolué au fil des projets sans documentation d'architecture à jour, et qui a besoin d'un état des lieux établi par un tiers expert.

Le problème traité : une infrastructure fonctionne rarement comme elle est décrite. Les schémas datent du projet initial, les évolutions successives n'ont pas été reprises, et personne ne dispose d'une vue consolidée des flux, des dépendances et des points de rupture. Le jour où il faut arbitrer un investissement, migrer, ou répondre à un auditeur, cette vue manque.

Ce que ça change : vous disposez d'un référentiel d'architecture opposable, et d'une lecture des risques par un tiers — ce qui n'a pas le même poids en comité qu'une analyse produite en interne.

Prérequis : accès en lecture aux consoles d'administration, entretiens avec les référents infrastructure, documentation existante même partielle.

Pour qui : un projet de renouvellement ou d'extension d'infrastructure à dimensionner avant consultation des intégrateurs, sur un parc virtualisé de plusieurs dizaines à plusieurs centaines de machines.

Le problème traité : la plupart des dimensionnements reposent sur les chiffres du constructeur, sur le report à l'identique des allocations existantes, ou sur une extrapolation. Le premier surdimensionne, le deuxième reconduit les erreurs d'allocation du parc actuel, le troisième ne résiste pas à la première question d'un comité d'investissement. Un dimensionnement défendable repose sur des mesures, des hypothèses explicites et un modèle que le client peut rejouer lui-même.

Ce que ça change : vous négociez avec les intégrateurs sur des chiffres qui vous appartiennent, et vous pouvez justifier chaque euro demandé — y compris la marge — devant un comité d'investissement.

Prérequis : droits de lecture pour la collecte, un référent infrastructure, et un interlocuteur métier par projet à venir pour en qualifier les besoins.

Pour qui : une DSI qui prépare une consultation d'intégrateurs, veut cadrer le marché avant de le lancer, et s'assurer ensuite que ce qui est livré correspond à ce qui a été commandé.

Le problème traité : sans cahier des charges technique indépendant, la consultation est cadrée par les intégrateurs eux-mêmes et les offres deviennent incomparables. Et un cahier des charges, même bien écrit, ne garantit rien seul : l'écart se creuse au déploiement, quand plus personne côté client n'a le temps ni l'expertise de vérifier ligne à ligne ce qui est réellement mis en œuvre.

Ce que ça change : vous définissez le terrain sur lequel les intégrateurs répondent, au lieu de choisir entre des propositions incomparables — et vous disposez, jusqu'à la réception, d'un référent technique qui défend vos intérêts et non ceux du fournisseur.

Prérequis : accès aux consoles d'administration, référent infrastructure, interlocuteurs métier pour la qualification des besoins. En phase 4 : accès aux livrables et au planning de l'intégrateur, et invitation aux points de suivi de chantier.

Pour qui : un intégrateur ou un revendeur qui répond à une consultation d'infrastructure et doit produire un profil expert au dossier, ou qui a besoin de renforcer son équipe sur un déploiement d'envergure.

Le problème traité : les marchés d'infrastructure — bancaires en particulier — sont notés sur les CV présentés autant que sur la solution proposée. Un dossier techniquement solide perd des points s'il ne peut aligner un profil certifié sur chaque brique. Et une fois le marché gagné, il faut tenir le planning avec les ressources réellement disponibles.

Modalités : sous-traitance ou portage, livrables à votre marque, engagement de confidentialité et de non-sollicitation de votre client. Disponibilité et périmètre confirmés avant tout engagement au dossier.

Pour qui : une organisation dont le parc et les identités se sont étendus plus vite que leur gouvernance.

Le problème traité : comptes orphelins, rôles privilégiés jamais revus, appareils non conformes accédant aux données, politiques empilées par strates successives.

Ce que ça change : vous savez qui accède à quoi, depuis quel appareil, et sous quelle condition.

Pour qui : une migration depuis Exchange, Lotus ou un environnement hybride à finaliser — et, au-delà de la messagerie, la mise en place du socle d'identité, de gestion des postes et de collaboration qui l'accompagne.

Le problème traité : une migration Microsoft 365 réussie ne se joue pas sur le transfert des boîtes aux lettres mais sur ce qui la précède et ce qui la suit — un annuaire propre, une synchronisation d'identité correctement conçue, une méthode d'authentification adaptée au contexte, et un socle de gestion des postes en place avant que les utilisateurs ne basculent. Sans cela, la bascule technique réussit et l'exploitation devient ingérable.

Ce que ça change : une bascule planifiée et réversible, sur un socle d'identité et de gestion des postes conçu pour durer — pas un basculement subi suivi de deux ans de rattrapage.

Prérequis : accès administrateur à l'annuaire et au tenant, tenant Microsoft 365 provisionné avec les licences requises, maîtrise de la zone DNS publique, référent poste de travail disponible.

Pour qui : une organisation qui étend son infrastructure vers Azure — extension du datacenter, site de secours, hébergement d'applications ou de nouveaux projets — et qui veut cadrer le besoin et le coût avant de s'engager.

Le problème traité : Azure se facture à l'usage, ce qui déplace le risque : il n'y a plus de surdimensionnement visible à la commande, mais une facture qui dérive mois après mois. Une infrastructure Azure conçue sans étude de besoin, sans modèle de coût et sans règles de gouvernance coûte durablement plus cher qu'un socle sur site — sans en avoir la prévisibilité.

Ce que ça change : vous savez ce que votre infrastructure Azure va coûter avant de la construire, et vous disposez des règles de gouvernance qui empêchent la facture de dériver ensuite.

Prérequis : souscription Azure ou accord d'entreprise en place, accès administrateur au tenant, maîtrise de l'adressage et des flux du réseau existant, référent sécurité pour les arbitrages d'exposition.

Pour qui : direction, COO, département informatique, responsables métier qui veulent intégrer l'IA dans leurs processus existants sans tout reconstruire.

Le problème traité : vous avez des systèmes en place (ERP, CRM, outils métier), des données éparses, et une envie d'IA. Mais par où commencer ? Quels processus cibler ? Faut-il tout remplacer ou connecter ce qui existe ? Quelle techno utiliser sans casser l'écosystème ?

Ce que ça change : vous avez une feuille de route claire pour intégrer l'IA sans disruption. Votre IT et vos équipes métier peuvent démarrer immédiatement la phase 1.

Pour qui : un cas d'usage cadré prêt à être mis en production après validation.

Le problème traité : vous avez identifié un processus à automatiser (extraction documentaire, classification, notification, enrichissement de données). Mais entre la théorie et l'exécution, il y a des questions : ça va marcher avec nos données ? Comment l'intégrer à nos systèmes ? Quels risques ? Quel coût réel ?

Ce que ça change : vous ne déployez pas un POC sans résultats — vous déployez un workflow qui a fait ses preuves sur vos données réelles. L'équipe IT sait comment le maintenir. Le business connaît le ROI.

Technologies : n8n · Copilot Studio

Le problème traité : beaucoup de formateurs proposent des formations Microsoft ou techniques — mais restent collés au contenu pédagogique officiel. Théorie, démos en labo, cas génériques. Vous repartez avec des certifications mais sans savoir gérer les vrais problèmes qu'on rencontre en production.

Pour qui : un besoin qui ne correspond à aucun catalogue standard.

Le problème traité : les formations génériques ne collent jamais à votre contexte. Vos équipes ont des niveaux différents, des lacunes spécifiques, et des systèmes déjà en place. Une formation « catalogue » ne vous aidera pas.

Ce que ça change : votre équipe maîtrise vraiment les technos — pas juste les avoir « vues ». Elle peut les mettre en place et les maintenir seule après. Les formations sont adaptées à votre contexte, pas génériques.

Modalités : langues : français, arabe, anglais. Format : chez le client ou à distance. Domaines disponibles : infrastructure, cloud, sécurité, IA, automatisation, Microsoft 365, sauvegarde et résilience.

Référence : programme Microsoft 365 avancé conçu pour éviter tout contenu basique, exclusivement centré sur les configurations avancées et les cas de production.

Pour qui : une organisation qui vient de déployer une plateforme et doit l'exploiter en autonomie.

Ce que ça change : l'équipe exploite sans rappeler le prestataire à chaque opération.

Référence : guide de dépannage Entra ID et Intune de 37 pages produit pour des équipes support N1/N2.