
L’infogérance co-managée, ou cogérance, n’est pas une simple « infogérance légère ».
C’est un modèle de collaboration où vous conservez une part essentielle du pilotage (décisions stratégiques, priorités, validation des budgets) tandis que le prestataire se charge de l’exécution opérationnelle (support, supervision, sécurité, projets définis).
Ce modèle est particulièrement adapté aux PME qui disposent d’un référent interne, même non-expert, et qui souhaitent garder la maîtrise de leur système d’information.
La réussite d’une telle collaboration repose sur trois piliers formalisés par écrit :
🔗 Pour aller plus loin, voir: explication complète de l’infogérance.
En synthèse, la cogérance est une organisation où le prestataire exécute et vous pilotez les aspects que vous ne souhaitez pas déléguer (priorités, arbitrages, règles de sécurité).
Le contrat doit matérialiser cette répartition à travers un RACI, un périmètre précis et des preuves d’exécution.
Ce modèle se distingue d’autres formes de services informatiques :
Pour une analyse plus détaillée des différences, vous pouvez consulter notre article Infogérance vs. Maintenance : quelles différences ?.
Le RACI est un outil simple pour clarifier les rôles et responsabilités.
Ne signez aucun contrat de cogérance sans un tableau de ce type, adapté à votre contexte.
Pourquoi c’est indispensable ? Parce que “co-managée” sans RACI devient une zone grise : personne ne décide, les urgences dictent tout, et vous payez pour gérer des malentendus.
| Sujet | Client (vous) | Prestataire | Fournisseur (éditeur/opérateur) | Preuve attendue |
|---|---|---|---|---|
| Support utilisateurs (tickets) | I | R | I | Export des tickets + temps + catégories |
| Arrivées/départs (comptes & accès) | A | R | C | Journal des actions + validation |
| Mises à jour des postes | A | R | I | Taux de conformité + exceptions |
| Exécution des sauvegardes | A | R | C | Rapport succès/échec + alertes |
| Test de restauration | A | R | C | Compte-rendu de test + temps réel |
| Supervision (alertes) | I | R | I | Rapport d’incidents + actions menées |
| Incident critique (rétablissement) | A | R | C | Chronologie + temps de rétablissement |
| Sécurité (EDR, phishing, etc.) | A | R | C | Rapport des mesures + preuves (logs) |
| Documentation (runbook, schémas) | A | R | I | Dossier à jour + accès client |
| Projets (migrations, etc.) | A | R | C | Plan projet + livrables + recette |
Un SLA utile ne se contente pas de promettre la « réactivité ». Il définit précisément ce qui est mesuré, comment, et sur quelles plages horaires.
Il est crucial de distinguer trois délais :
Un dirigeant se soucie peu qu’on lui « réponde en 15 minutes » si son activité reste bloquée pendant des heures. L’engagement sur le temps de rétablissement (GTR) est souvent le plus important.
En cogérance, le prestataire doit exécuter et rendre compte, notamment pour la cybersécurité (voir guide). Le reporting n’est pas une formalité, c’est l’outil qui vous permet de garder le contrôle et de piloter l’amélioration continue.
Dès que votre prestataire gère des données personnelles, il devient votre sous-traitant au sens du RGPD. Cette relation doit être encadrée par un contrat écrit (DPA) conforme à l’article 28.
Exigez la liste des sous-traitants ultérieurs (hébergeur, éditeur de logiciel de sauvegarde, etc.). La CNIL insiste sur la maîtrise de toute la chaîne de sous-traitance. Pour en savoir plus, consultez notre guide sur l’infogérance et le RGPD.
Les deux concepts clés à définir sont :
Le point non négociable reste les tests réguliers de restauration. Sans eux, votre plan de reprise n’est qu’un document théorique.
En cogérance, mettez noir sur blanc :
Pour aller plus loin: guide PRA officiel
La réversibilité ne consiste pas seulement à « récupérer vos données ». C’est la capacité à repartir avec un autre prestataire ou en interne sans blocage ni perte d’information. Pour cela, une clause de réversibilité (guide dédié) est indispensable.
Votre checklist de sortie doit inclure au minimum : les accès administrateur, la documentation complète (schémas, inventaire, procédures), l’historique des tickets et les rapports.
Pour une trame complète, vous pouvez utiliser notre modèle de cahier des charges pour l’infogérance.
En co-managée, vous gardez une partie du pilotage (décisions, priorités, validations). En infogérance complète, le prestataire porte davantage le pilotage. Dans les deux cas, c’est le contrat (périmètre, RACI, SLA, preuves) qui fait la différence.
Opérationnellement, le prestataire est responsable de ce qu’il exécute (selon le RACI). Mais la responsabilité “globale” dépend du contrat, des obligations RGPD, et de la chaîne de fournisseurs.
Oui : c’est ce qui empêche les zones grises (“je pensais que c’était vous”). C’est particulièrement critique sur les accès, les sauvegardes, les incidents et la sécurité.
Non. Il faut au minimum un engagement sur le rétablissement sur incidents critiques, pas seulement sur la lecture du ticket.
Tickets (volumes/catégories), délais de rétablissement, backlog, patching, sauvegardes, tests de restauration, incidents sécurité, documentation.
Un contrat écrit encadrant le traitement : nature/finalité/durée, types de données, mesures de sécurité, sous-traitance ultérieure, assistance, restitution/suppression en fin de prestation, etc.
Commencez par identifier 3–5 processus critiques, définir des objectifs RTO/RPO réalistes, puis mettre en place des sauvegardes et tester la restauration (sinon vous ne savez pas si vous pouvez repartir).
En prévoyant la réversibilité dès le départ : liste des livrables, accès, documentation, exports, délais, assistance de passation.
Si vous êtes une PME à Paris ou en Île-de-France, la démarche la plus efficace est de commencer par un cadrage court pour définir vos besoins (périmètre, RACI, SLA) avant de comparer les offres.
Cela vous permet de choisir un prestataire d’infogérance à Paris sur des bases factuelles et non sur de simples promesses.