Trainer · Independent IT Consultant · Founder of REC-IT & DossiMed.ai

Who it's for: any IT department that has not tested a full restore in more than six months, or has no up-to-date record of what it protects.

The problem: a backup platform that runs without visible errors is not a platform that restores. And you cannot properly protect what you have never inventoried: without documented criticality, the same policy applies everywhere.

What changes: you hold a defensible record of what you protect, and you know, with evidence, what would restart and what would not.

Prerequisites: read access to the backup console, a technical point of contact, a test window.

Who it's for: a Commvault or Veeam platform that is saturating, failing, or no longer holding its backup windows.

The problem: degraded performance, job queues piling up, roles concentrated on a single server, an undersized configuration database.

What changes: the platform holds its backup windows again, with figures to prove it.

Prerequisites: administrator access, an intervention window, an infrastructure contact available.

Who it's for: an organisation that must guarantee the recovery of a critical system after a disaster, and has to choose between a physical site, a sovereign cloud and a public cloud.

The problem: a written recovery plan is not a recovery plan. Without an RTO/RPO matrix validated by the business, without a sized replication architecture and without a tested failover plan, the document remains an intention — and without a costed comparison of hosting scenarios, the investment decision is made blind.

What changes: a recovery commitment you can defend before an executive committee or a regulator, and an investment decision based on compared scenarios rather than on a single quotation.

Prerequisites: access to the application inventory and data volumes, a business contact to arbitrate RTOs and RPOs, the regulatory constraints on data location.

Who it's for: an organisation with a documented recovery plan that has never been exercised, or whose last exercise is more than a year old.

The problem: the first real test invariably reveals undocumented dependencies — a secondary service, a name resolution, a service account, a start-up order. Better to discover them on a day you choose than on a day imposed on you.

What changes: your recovery plan moves from being a document to being a demonstrated capability, with an exercise record that stands up in an audit.

Prerequisites: a recovery environment available, a validated exercise window, infrastructure and business teams available for the duration of the exercise.

Who it's for: a deployment, migration or full rebuild of the backup platform, from the rack to the first validated restore.

The problem: a backup platform is not judged on its software installation but on its full chain — a poorly cabled foundation or incomplete SAN zoning degrades performance long after go-live, and is paid for in backup windows that overrun.

What changes: a platform operated by your own teams, documented and proven from go-live — not dependent on a supplier.

Prerequisites: hardware and licences procured, datacenter access, address ranges and network flows opened, an infrastructure contact available.

Who it's for: an IT department whose datacenter and secondary site have grown project by project without up-to-date architecture documentation, and which needs an assessment established by an expert third party.

The problem: an infrastructure rarely works the way it is described. The diagrams date from the original project, successive changes were never folded back in, and nobody holds a consolidated view of the flows, the dependencies and the points of failure. The day an investment has to be arbitrated, a migration launched, or an auditor answered, that view is missing.

What changes: you hold an architecture record that stands up to scrutiny, and a reading of the risks by a third party — which does not carry the same weight in committee as an analysis produced in-house.

Prerequisites: read access to the administration consoles, interviews with the infrastructure contacts, existing documentation even if partial.

Who it's for: an infrastructure renewal or extension project to be sized before consulting integrators, on a virtualised estate of several dozen to several hundred machines.

The problem: most sizing exercises rest on vendor figures, on carrying existing allocations across unchanged, or on extrapolation. The first oversizes, the second carries over the allocation errors of the current estate, and the third does not survive the first question from an investment committee. A defensible sizing rests on measurements, on explicit assumptions, and on a model the client can re-run themselves.

What changes: you negotiate with integrators on figures that are yours, and you can justify every euro requested — including the margin — before an investment committee.

Prerequisites: read rights for the collection, an infrastructure contact, and one business contact per upcoming project to qualify its requirements.

Who it's for: an IT department preparing a tender to integrators, wanting to frame the market before launching it, and then to make sure that what is delivered matches what was ordered.

The problem: without an independent technical requirements document, the tender is framed by the integrators themselves and the bids become impossible to compare. And a requirements document, however well written, guarantees nothing on its own: the gap widens during deployment, when nobody on the client side has the time or the expertise to check line by line what is actually being implemented.

What changes: you define the ground on which integrators bid, instead of choosing between proposals that cannot be compared — and you have, all the way to sign-off, a technical representative defending your interests rather than the supplier's.

Prerequisites: access to the administration consoles, an infrastructure contact, business contacts to qualify the requirements. In phase 4: access to the integrator's deliverables and schedule, and an invitation to the project review meetings.

Who it's for: an integrator or reseller bidding on an infrastructure tender who must put an expert profile in the file, or who needs to reinforce their team on a large deployment.

The problem: infrastructure tenders — banking ones in particular — are scored on the CVs presented as much as on the solution proposed. A technically sound bid loses points if it cannot put a certified profile against each building block. And once the contract is won, the schedule has to be held with the resources actually available.

Terms: subcontracting or umbrella arrangement, deliverables under your brand, confidentiality and non-solicitation undertakings towards your client. Availability and scope confirmed before any commitment in the bid file.

Who it's for: an organisation whose estate and identities have grown faster than their governance.

The problem: orphaned accounts, privileged roles never reviewed, non-compliant devices accessing data, policies stacked in successive layers.

What changes: you know who accesses what, from which device, and under which condition.

Who it's for: a migration from Exchange, Lotus or a hybrid environment still to be completed — and, beyond mail, the identity, device management and collaboration foundation that goes with it.

The problem: a successful Microsoft 365 migration is not decided on the mailbox transfer but on what precedes it and what follows — a clean directory, a properly designed identity synchronisation, an authentication method suited to the context, and a device management foundation in place before users move across. Without that, the technical cutover succeeds and day-to-day operations become unmanageable.

What changes: a planned and reversible cutover, on an identity and device management foundation built to last — not a cutover endured, followed by two years of catching up.

Prerequisites: administrator access to the directory and to the tenant, a Microsoft 365 tenant provisioned with the required licences, control of the public DNS zone, an endpoint contact available.

Who it's for: an organisation extending its infrastructure into Azure — datacenter extension, recovery site, hosting of applications or of new projects — and wanting to frame the requirement and the cost before committing.

The problem: Azure is billed on consumption, which shifts the risk: there is no longer any visible oversizing at order time, but an invoice that drifts month after month. An Azure infrastructure designed without a requirements study, without a cost model and without governance rules ends up costing more than an on-premises foundation — without its predictability.

What changes: you know what your Azure infrastructure will cost before you build it, and you hold the governance rules that keep the invoice from drifting afterwards.

Prerequisites: an Azure subscription or enterprise agreement in place, administrator access to the tenant, command of the existing network addressing and flows, a security contact for exposure decisions.

Who it's for: executives, COOs, IT departments and business owners who want to bring AI into their existing processes without rebuilding everything.

The problem: you have systems in place (ERP, CRM, line-of-business tools), scattered data, and an appetite for AI. But where do you start? Which processes do you target? Do you replace everything or connect what exists? Which technology can you use without breaking the ecosystem?

What changes: you have a clear roadmap for bringing AI in without disruption. Your IT and business teams can start phase 1 immediately.

Who it's for: a scoped use case, ready to go into production once validated.

The problem: you have identified a process to automate (document extraction, classification, notification, data enrichment). But between theory and execution lie the real questions: will it work on our data? How do we integrate it with our systems? What are the risks? What does it actually cost?

What changes: you are not deploying a proof of concept with nothing to show — you are deploying a workflow that has proven itself on your real data. The IT team knows how to maintain it. The business knows the return.

Technologies: n8n · Copilot Studio

The problem: many trainers offer Microsoft or technical courses — but stay glued to the official teaching material. Theory, lab demos, generic cases. You leave with certifications but without knowing how to handle the real problems you meet in production.

Who it's for: a requirement that matches no standard catalogue.

The problem: generic courses never fit your context. Your teams have different levels, specific gaps, and systems already in place. An off-the-shelf course will not help you.

What changes: your team genuinely masters the technologies — not merely "seen" them. They can implement and maintain them on their own afterwards. The courses are adapted to your context, not generic.

Terms: languages: French, Arabic, English. Format: at the client's site or remote. Available domains: infrastructure, cloud, security, AI, automation, Microsoft 365, backup and resilience.

Reference: an advanced Microsoft 365 programme designed to avoid any basic content, focused exclusively on advanced configurations and production cases.

Who it's for: an organisation that has just deployed a platform and has to operate it on its own.

What changes: the team operates without calling the supplier back for every task.

Reference: a 37-page Entra ID and Intune troubleshooting guide produced for level 1/2 support teams.