Mémoire technique informatique : structure et modèle IT

Un marché public de services informatiques — TMA, infogérance, développement, hébergement, cybersécurité — pose des exigences de mémoire technique que les guides généralistes ne couvrent jamais : SLA avec GTI/GTR chiffrés, certifications ITIL ou Scrum nommées sur des profils identifiés, architecture technique justifiée, réversibilité documentée, conformité RGPD et ANSSI. Un mémoire qui répond "nous disposons d'équipes expérimentées en informatique" sera noté entre 8 et 11 sur 20 quelle que soit la réalité de votre offre. L'acheteur public veut la preuve sectorielle dans le document lui-même.

Cet article décrit la structure type d'un mémoire technique pour un marché IT, avec un tableau des exigences CCTP par segment (TMA, infogérance, développement, hébergement) et des extraits commentés. Pour les fondamentaux communs à tous les secteurs, lisez d'abord le guide complet du mémoire technique de marché public et notre article sur la structure type d'un mémoire technique. Pour identifier les critères sur lesquels vous serez noté avant de rédiger, consultez l'article sur les critères de notation en marché public.

Spécificités d'un marché public de services informatiques

Le secteur IT en commande publique recouvre des périmètres radicalement différents, chacun avec ses critères propres. Avant d'écrire la première ligne du mémoire, identifiez dans quel segment vous vous positionnez :

• TMA (Tierce Maintenance Applicative) : maintenance corrective, évolutive et adaptative d'un ou plusieurs applicatifs existants. L'acheteur évalue votre capacité à reprendre une application inconnue, votre processus de prise en main, et vos engagements de délai de résolution.
• Infogérance : externalisation de tout ou partie de l'infrastructure informatique (serveurs, réseau, postes de travail, helpdesk). Les critères portent sur les SLA, la supervision, le plan de continuité et la réversibilité.
• Développement (forfait ou régie) : réalisation d'une application ou d'un module. La méthodologie (Agile, cycle en V, hybride), la gouvernance projet et la recette sont les axes principaux d'évaluation.
• Hébergement et cloud : hosting d'applications ou de données publiques. Les enjeux sont la localisation des données, le niveau de service, la souveraineté numérique (SecNumCloud, HDS), et la réversibilité.
• AMOA / AMOE : assistance à maîtrise d'ouvrage ou d'oeuvre. L'acheteur évalue l'indépendance des profils, leur expérience sectorielle, et la méthode de conduite du changement.
• Cybersécurité : audit, SOC, gestion des vulnérabilités, conformité. Les certifications (ISO 27001, PASSI, CESTI) et les référentiels ANSSI sont les premiers filtres de l'acheteur.

Cette segmentation détermine les sections à développer en priorité. Un mémoire TMA qui consacre la moitié de ses pages à l'architecture cloud alors que le CCTP porte uniquement sur la maintenance d'un ERP interne sera sous-noté, même si le contenu est techniquement solide. Pour apprendre à lire le CCTP et identifier les attentes implicites de l'acheteur, consultez notre méthode pour analyser un DCE en moins d'une heure.

Tableau : exigences CCTP types par segment IT et réponse attendue dans le mémoire

Le tableau ci-dessous synthétise les exigences les plus fréquentes par type de marché IT et ce que l'acheteur attend en réponse dans le mémoire technique. Il ne remplace pas la lecture du CCTP — il vous donne le cadre de référence pour interpréter les formulations habituelles.

Segment IT	Exigences CCTP types	Ce que le mémoire doit apporter
TMA	Délais de prise en charge, maintien en condition opérationnelle, gestion des évolutions mineures, reporting mensuel	Processus de prise en main documenté, GTI/GTR par niveau de criticité, outil de ticketing proposé, tableau de bord de suivi, exemples de reprise TMA similaires
Infogérance	Supervision 24/7, helpdesk niveaux 1-2-3, gestion des mises à jour, gestion des incidents, PRA/PCA	Architecture de supervision (outil, périmètre, alertes), organigramme de l'équipe support avec astreintes, procédure d'escalade, RTO/RPO du PRA, référence à un PCA testé
Développement	Méthodologie projet, gestion du backlog, recette, gestion des risques, livrables intermédiaires	Méthode choisie (Agile/cycle en V/hybride) justifiée au regard du CCTP, composition de l'équipe avec rôles Scrum, planning avec jalons de recette, gestion des anomalies
Hébergement / cloud	Localisation des données, disponibilité (SLA), sauvegarde, supervision, réversibilité, souveraineté	Datacenters nommés et certifiés (ISO 27001, HDS le cas échéant), taux de disponibilité garanti avec pénalités, politique de sauvegarde (fréquence, rétention, tests), plan de réversibilité technique
AMOA / AMOE	Indépendance vis-à-vis des éditeurs, expérience sectorielle, conduite du changement, livrables	CV des profils nommés avec références similaires dans le secteur public, positionnement méthodologique (méthode de conduite du changement, livrables types), dispositif de formation
Cybersécurité	Référentiels (ANSSI, ISO 27001, PSSIE), certifications des auditeurs (PASSI, CESTI), gestion des vulnérabilités	Certifications nommées avec dates de validité, méthodologie d'audit référencée (PASSI le cas échéant), livrables types (rapport d'audit, plan de remédiation), clause de confidentialité

Section 1 — Compréhension du besoin et enjeux métier

C'est la section la plus différenciante et la plus souvent bâclée. Elle doit montrer que vous avez lu et compris le CCTP dans sa dimension métier, pas seulement technique. Pour un marché de TMA sur un système de gestion RH d'une collectivité, l'acheteur veut voir que vous avez identifié les contraintes spécifiques : cycles de paie, interface avec la DGFIP, contraintes de disponibilité en période de clôture mensuelle.

Ce que cette section doit contenir :

• Reformulation synthétique du besoin avec les mots du CCTP (références aux paragraphes)
• Identification des contraintes métier non techniques : saisonnalité, utilisateurs clés, contraintes réglementaires sectorielles
• Risques identifiés sur le projet et mesures d'atténuation proposées
• SLA attendus tels que formulés dans le CCTP, avec votre positionnement par rapport à ces attentes

Section 2 — Méthodologie projet : Agile, cycle en V ou hybride ?

Le choix de la méthodologie ne doit jamais être présenté comme un dogme. Il doit être justifié au regard du CCTP. Sur un marché de développement avec un périmètre fonctionnel figé et un délai ferme, le cycle en V reste défendable. Sur un marché de développement en contexte évolutif avec des parties prenantes multiples, l'Agile (Scrum ou Kanban) s'impose. Sur un marché de TMA, le modèle ITIL s'applique naturellement à la gestion des incidents et des demandes.

• Méthode Agile / Scrum : à privilégier quand le CCTP mentionne "sprints", "backlog", "recette itérative" ou "évolutions fréquentes". Précisez : durée des sprints, composition de l'équipe Scrum (Product Owner côté client identifié ou proposé, Scrum Master nommé, équipe de développement avec taux d'occupation), cérémonies (planning, daily, review, rétrospective), outil de gestion du backlog (Jira, Azure DevOps, GitLab).
• Cycle en V : adapté aux marchés à périmètre figé avec phases contractuelles (conception, réalisation, recette, déploiement). Présentez le découpage en phases avec jalons de validation, la gestion des anomalies de recette (workflow : signalement, qualification, correction, validation) et les critères d'entrée et de sortie de chaque phase.
• Modèle hybride : pour les marchés qui combinent un socle technique structurant (cycle en V) et des évolutions fonctionnelles récurrentes (sprints). Expliquez quelle partie du périmètre relève de chaque régime et comment les deux modes coexistent sans collision.

Quel que soit le modèle choisi, précisez les outils proposés (forge logicielle, gestionnaire de tickets, outil de documentation) en cohérence avec l'environnement technique de l'acheteur décrit dans le CCTP.

Section 3 — Équipe et profils : la section la plus sous-notée

C'est la section où l'écart entre candidats se creuse le plus. Un mémoire qui présente "une équipe de 5 consultants expérimentés" sans nommer personne, sans certification précise, sans taux d'occupation sera noté 10. Un mémoire qui présente chaque profil nominativement sera noté 16 à 18.

Pour chaque profil, fournissez :

• Nom et prénom (ou initiaux si le RC interdit le nommage, mais certains RC l'exigent explicitement)
• Rôle dans le marché : chef de projet, architecte, développeur senior, technicien support N2
• Taux d'occupation sur ce marché exprimé en pourcentage ou en jours/mois
• Certifications pertinentes : ITIL 4 Foundation ou Expert (infogérance), Scrum Master CSM/PSM (Agile), PMP ou Prince2 (gestion de projet), certifications éditeur (AWS, Azure, GCP), CISSP/CISM (cybersécurité), qualification PASSI ANSSI
• Expériences similaires : 1-2 références dans le secteur public avec nature du marché et résultats mesurables

Si le RC interdit la nomination des personnes physiques (pratique de certains acheteurs pour éviter le débauchage), adaptez : "Profil A — Chef de projet certifié PMP, 8 ans d'expérience en TMA secteur public, intervenu sur 4 marchés similaires de plus de 500 K€". L'absence de taux d'occupation est une erreur fréquente qui laisse l'acheteur sans visibilité sur la réalité de l'engagement de vos ressources clés. Pour les leviers qui font progresser la note de 3 à 5 points, voir notre article sur améliorer la note du mémoire technique.

Section 4 — Architecture technique proposée

Cette section s'applique principalement aux marchés de développement, d'hébergement et d'infogérance. Elle doit justifier chaque choix technique en référence aux contraintes du CCTP — pas présenter votre stack habituel.

Éléments à inclure :

• Schéma d'architecture : inclure un schéma légendé (même simplifié) montrant les composants, leurs interactions, les flux de données et les points de sécurité. Un schéma bien fait vaut souvent plus qu'une page de texte.
• Justification des choix : pourquoi cette technologie plutôt qu'une autre ? En quoi est-elle cohérente avec l'environnement existant décrit dans le CCTP ? Mentionnez explicitement les contraintes de compatibilité avec les systèmes de l'acheteur.
• Alternatives étudiées : mentionner que vous avez évalué d'autres options et expliquer pourquoi vous les avez écartées renforce la crédibilité de votre proposition.
• Environnements : précisez les environnements proposés (développement, intégration, pré-production, production) et les procédures de déploiement entre eux (CI/CD, procédure de mise en production, gel des déploiements en période critique).

Section 5 — Sécurité et conformité : RGPD, ANSSI, SecNumCloud, HDS

La sécurité est systématiquement un sous-critère dans les marchés IT publics. L'acheteur public est lui-même soumis à la PSSIE (Politique de Sécurité des Systèmes d'Information de l'État) et au RGPD — il cherche un prestataire qui maîtrise ces référentiels, pas un qui les mentionne en liste de bullet points.

Quels référentiels citer selon le marché ?

• Tous les marchés IT : RGPD (rôle de sous-traitant de données, DPA, localisation des données en UE), PSSIE pour les marchés État, RGS (Référentiel Général de Sécurité) pour les téléservices publics
• Marchés d'hébergement de données sensibles : qualification SecNumCloud ANSSI (exigée ou recommandée dans de nombreux marchés État depuis 2022), norme ISO 27001 du datacenter
• Marchés de santé / médico-social : certification HDS (Hébergeur de Données de Santé) obligatoire si les données traitées relèvent de l'article L.1111-8 du Code de la santé publique
• Marchés cybersécurité : qualification PASSI ANSSI (Prestataire d'Audit de Sécurité des SI), certification ISO 27001 propre, méthode EBIOS Risk Manager

Comment présenter la conformité RGPD dans le mémoire ?

Ne vous contentez pas d'écrire "nous sommes conformes au RGPD". Précisez : votre statut de sous-traitant au sens de l'article 28 du RGPD, les mesures techniques et organisationnelles (chiffrement des données au repos et en transit, gestion des accès, traçabilité des opérations), la procédure de notification de violation de données dans les 72h, et la localisation des données dans l'UE. Proposez un DPA (Data Processing Agreement) prêt à signer — c'est un signal fort pour l'acheteur.

Section 6 — Réversibilité et transition : le sous-critère que personne ne traite correctement

Sur les marchés pluriannuels (infogérance, TMA, hébergement), la réversibilité est systématiquement un critère ou un sous-critère. Pourtant, 80 % des mémoires la traitent en deux lignes génériques. C'est un gain de points facile si vous y consacrez une section structurée.

Un plan de réversibilité complet comprend :

• Transition entrante : comment vous reprenez le marché depuis le titulaire sortant. Détaillez : durée de la phase de transition (en semaines), livrables attendus du sortant (documentation, cartographie, accès), ressources dédiées à la reprise (nom ou profil, taux d'occupation pendant la transition), critères de réception de la transition.
• Transition sortante : comment vous transmettez le marché à votre successeur en fin de contrat. Engagement sur la durée de la transition sortante, livrables que vous produirez (documentation à jour, cartographie, inventaire, formation du successeur), conditions financières de la transition sortante (incluse dans le forfait ou en régie sur option).
• Documentation maintenue à jour : précisez l'outil (wiki, base de connaissances ITSM), la fréquence de mise à jour, et le responsable de la documentation au sein de votre équipe.

Section 7 — SLA, GTI, GTR : tableau d'engagements de service

Le tableau SLA/GTI/GTR est l'élément le plus visible pour l'acheteur sur les marchés d'infogérance et de TMA. Un tableau bien construit, avec des niveaux de criticité différenciés et des pénalités proposées, transforme une section narrative en engagement contractuel évaluable objectivement.

Niveau de criticité	Définition type	GTI proposé	GTR proposé	Pénalité par dépassement
P1 — Bloquant	Application principale indisponible, impact total sur la production	30 min	4h	1/1 000 du montant mensuel par heure de dépassement
P2 — Majeur	Fonctionnalité critique dégradée, contournement possible	2h	NBJ + 1	1/2 000 du montant mensuel par jour de dépassement
P3 — Mineur	Anomalie sans impact sur la production, évolution mineure	NBJ + 1	5 NBJ	Sans pénalité contractuelle, suivi en comité mensuel
P4 — Amélioration	Demande d'évolution planifiée	5 NBJ	Selon backlog priorisé	Sans pénalité, délai négocié en comité trimestriel

GTI = Garantie de Temps d'Intervention (délai pour accusé de réception et prise en charge). GTR = Garantie de Temps de Rétablissement (délai pour résolution complète). NBJ = nombre de jours ouvrés. Adaptez les valeurs à votre réalité opérationnelle — proposer un GTR de 2h sur un P1 que vous ne pouvez pas tenir est une erreur contractuelle grave.

Section 8 — Pilotage : comitologie et reporting

L'acheteur public veut une visibilité structurée sur l'exécution du marché. Votre dispositif de pilotage doit être précis et proportionné à la taille du marché.

• Comité opérationnel (mensuel) : suivi des tickets, des SLA, des incidents, des demandes en cours. Participants : responsable technique titulaire et référent DSI acheteur. Support : tableau de bord mensuel transmis 48h avant la réunion.
• Comité de pilotage (trimestriel ou semestriel) : bilan contractuel, points d'amélioration, évolutions du périmètre, plan de charge à venir. Participants : directeur de compte titulaire et DGA ou DSI acheteur.
• Indicateurs de performance (KPI) : taux de respect des GTI/GTR par criticité, taux de disponibilité applicatif (exprimé en 99,x %), volume de tickets traités par type, délai moyen de résolution.
• Tableau de bord : précisez le format (portail web, PDF mensuel, outil ITSM partagé), la fréquence et l'accès (lecture seule pour l'acheteur sur votre outil de ticketing est souvent apprécié).

Section 9 — Continuité d'activité : PRA et PCA

Sur les marchés d'infogérance et d'hébergement, le Plan de Reprise d'Activité (PRA) et le Plan de Continuité d'Activité (PCA) sont des livrables attendus ou des sous-critères explicites. Ne les confondez pas :

• PCA (Plan de Continuité d'Activité) : comment vous maintenez un niveau de service dégradé mais opérationnel pendant un sinistre (panne majeure, cyberattaque, sinistre physique). Précisez le mode dégradé proposé, le niveau de service minimal garanti en mode PCA, et les conditions de déclenchement.
• PRA (Plan de Reprise d'Activité) : comment vous rétablissez le service nominal après un sinistre. Précisez le RTO (Recovery Time Objective — délai maximal de reprise) et le RPO (Recovery Point Objective — perte de données maximale acceptable), les procédures techniques de bascule, et la fréquence des tests du PRA.

Indiquez si votre PRA a été testé en situation réelle ou en exercice, avec la date du dernier test. Un PRA non testé est un engagement théorique — l'acheteur public le sait.

Section 10 — Démarche RSE et numérique responsable

Le numérique responsable est un critère de plus en plus fréquent dans les marchés IT publics, notamment depuis la loi REEN du 15 novembre 2021 (Réduction de l'empreinte environnementale du Numérique). Même si ce n'est pas un critère explicite dans votre RC, l'aborder valorise votre offre.

• Sobriété des usages : politique interne de réduction de l'impact carbone des déplacements (préférence visioconférence, interventions regroupées), bilan carbone de la DSI si disponible
• Green IT sur les infrastructures : PUE (Power Usage Effectiveness) du datacenter proposé, recours à des énergies renouvelables, politique de recyclage du matériel
• Allongement de la durée de vie du parc : politique de reconditionnement, réemploi des équipements en fin de contrat
• Label ou référentiel : label NR (Numérique Responsable) de l'INR, référentiel GreenIT, indice de réparabilité des équipements proposés

Erreurs fréquentes dans un mémoire technique IT

En plus des erreurs communes à tous les mémoires techniques, le secteur IT a ses pièges propres :

• Copier-coller commercial : extraire des sections de votre plaquette commerciale en remplaçant le nom du client. L'acheteur lit des dizaines de mémoires — il reconnaît immédiatement le contenu générique non adapté au CCTP. C'est la cause la plus fréquente de note inférieure à 12.
• Méthodologie sans justification : annoncer "nous utilisons Scrum" sans expliquer en quoi Scrum est pertinent au regard des contraintes du CCTP (livraisons itératives, parties prenantes multiples, périmètre évolutif). Sur un marché à périmètre figé, proposer Scrum sans justification peut être perçu comme un manque de maîtrise.
• Équipe non nominative : "une équipe de consultants seniors" sans noms, certifications ni taux d'occupation est systématiquement sous-noté. La section profils est souvent pondérée à 20-30 % du critère valeur technique.
• SLA non différenciés : un GTR unique pour tous les incidents, sans distinction par niveau de criticité, signale une absence de maturité ITSM. Sur les marchés d'infogérance, c'est une erreur éliminatoire sur le sous-critère engagements de service.
• Réversibilité traitée en une ligne : "nous assurerons une transition en bonne intelligence avec le titulaire entrant" ne constitue pas un plan de réversibilité. L'acheteur qui engage un prestataire sur 3 à 5 ans a un intérêt direct à la qualité du plan de sortie — traitez-le sérieusement.
• Conformité RGPD déclarative : écrire "nous respectons le RGPD" sans mesures concrètes, sans mention du DPA, sans localisation des données n'a aucune valeur pour un acheteur public soumis aux mêmes obligations.

Pour identifier les fragilités de votre mémoire avant dépôt, consultez notre article sur l'audit de mémoire technique et notre guide sur comment rédiger un mémoire technique qui passe en revue la méthode de rédaction section par section.

Pour aller plus loin

• Guide complet du mémoire technique de marché public 2026
• Structure type d'un mémoire technique : plan commenté
• Comment rédiger un mémoire technique : méthode et conseils
• 9 leviers pour améliorer la note du mémoire technique
• 7 erreurs qui éliminent automatiquement une candidature
• Audit de mémoire technique : comment identifier les fragilités avant dépôt
• Comprendre les critères de notation d'un marché public

Un mémoire technique IT qui obtient 16-18/20 ne liste pas des compétences — il prouve, section par section, que vous avez absorbé les contraintes du CCTP et que chaque engagement (SLA, profil, architecture, réversibilité) est dimensionné pour ce marché précis. Créez votre compte Olra pour analyser votre prochain DCE informatique et construire un plan de mémoire calibré sur les sous-critères réels de votre RC.

Questions fréquentes

Quelle est la structure type d'un mémoire technique pour un marché de TMA ?

Un mémoire TMA doit couvrir : (1) la compréhension du besoin et des enjeux métier de l'application concernée, (2) la méthodologie de prise en main et le processus de reprise depuis le titulaire sortant, (3) l'organisation de l'équipe avec les profils nommés et leur taux d'occupation, (4) le tableau SLA/GTI/GTR différencié par niveau de criticité, (5) les outils de ticketing et de reporting proposés, (6) le dispositif de pilotage (comités, tableau de bord mensuel), et (7) le plan de réversibilité sortante. La pondération sur les SLA et les profils est généralement plus forte que sur l'architecture technique.

Faut-il obligatoirement nommer les personnes dans un mémoire technique informatique ?

Cela dépend du règlement de consultation. Certains RC exigent les CV nominatifs en annexe. D'autres interdisent le nommage pour éviter les pratiques de débauchage entre titulaires successifs — dans ce cas, présentez des "profils types" avec années d'expérience, certifications précises et références de marchés similaires. Dans tous les cas, évitez les descriptions génériques : "consultant senior" sans précision est systématiquement sous-noté. La règle est : plus vous êtes précis, mieux vous êtes noté.

La qualification SecNumCloud est-elle obligatoire pour répondre à un marché d'hébergement public ?

SecNumCloud n'est pas universellement obligatoire, mais la circulaire du Premier ministre du 5 juillet 2021 recommande son exigence pour les systèmes d'information sensibles de l'État. Depuis 2022, de nombreux marchés ministériels l'exigent comme condition de candidature. Vérifiez le RC et le CCTP : si SecNumCloud n'est pas une condition d'admissibilité mais un critère de notation, vous pouvez candidater sans cette qualification, mais votre note sur le sous-critère sécurité sera pénalisée. Pour les données de santé, la certification HDS (Hébergeur de Données de Santé) est elle, obligatoire légalement.

Comment choisir entre Agile et cycle en V dans un mémoire technique de développement ?

Le choix doit être justifié au regard du CCTP, pas imposé par votre habitude interne. Si le CCTP mentionne un périmètre fonctionnel détaillé et figé, un délai ferme et un budget fixe, le cycle en V est plus défendable. Si le CCTP mentionne des livraisons itératives, des évolutions fonctionnelles attendues, ou la participation d'utilisateurs métier dans la validation, l'Agile est pertinent. Un modèle hybride (socle en cycle en V, évolutions en sprints) peut être pertinent sur des marchés de développement complexes. L'erreur à éviter est d'annoncer Agile sans décrire les cérémonies, les rôles Scrum et le mode de gestion du backlog — cela signale une méconnaissance de la méthode.

Quelle longueur pour un mémoire technique de marché informatique ?

Le RC fixe souvent une limite de pages (entre 20 et 50 pages selon la complexité du marché). Respectez-la impérativement — une offre hors format peut être rejetée pour non-conformité. En l'absence de limite, calibrez votre volume sur la pondération des critères : si les SLA et les profils représentent 40 % de la note technique, ces sections méritent proportionnellement 40 % des pages. Une section traitée en une demi-page alors qu'elle pèse 20 % dans la grille est systématiquement sous-notée, quelle que soit la qualité du reste du mémoire.