Sécurité offensive
Gouvernance & conformité
Protection des données
Une migration cloud, une nouvelle application métier, un SaaS branché sur votre SI : chaque projet peut abaisser votre niveau de sécurité s’il n’est sécurisé qu’en fin de parcours. L’ISP (intégration de la sécurité dans les projets) prend le problème à l’endroit : la sécurité entre dans le projet dès le cadrage, au même rang que le budget et les fonctionnalités.
Vous préparez un projet sensible ? Voir notre accompagnement à l’intégration de la sécurité dans les projets.
Ce qu’il faut retenir
- L’ISP (intégration de la sécurité dans les projets) fait entrer la cybersécurité dès le lancement d’un projet, pas après la mise en production.
- Rien à voir avec le fournisseur d’accès internet : en cybersécurité, ISP désigne une démarche de security by design.
- Corriger une faille en production coûte beaucoup plus cher que la prévenir en conception.
- La démarche couvre tout le cycle : cadrage, analyse de risques, définition des mesures, recette sécurité, mise en production, clôture.
- Elle maintient la conformité (RGPD, ISO 27001, NIS 2, DORA) au fil des évolutions du SI.
- Elle se pilote et s’outille : référentiel d’exigences, intégration à la méthodologie projet, digitalisation du suivi.
Qu’est-ce que l’ISP (intégration de la sécurité dans les projets) ?
L’ISP est une démarche qui consiste à identifier les risques d’un projet et à intégrer les exigences de cybersécurité et de protection des données dès son lancement. Concrètement : chaque projet qui touche au système d’information (nouvelle application, migration, refonte, interconnexion) embarque un volet sécurité, du cadrage à la mise en production.
Levons l’ambiguïté : en anglais, ISP signifie Internet Service Provider, le fournisseur d’accès internet. En cybersécurité, le sigle désigne l’intégration de la sécurité dans les projets. C’est de cette démarche qu’il s’agit ici.
L’ISP est la déclinaison opérationnelle du security by design : plutôt que d’auditer un produit fini et de corriger après coup, on définit les mesures de sécurité pendant la conception. Côté données personnelles, elle rejoint le privacy by design imposé par le RGPD.
Pourquoi intégrer la sécurité dès le cadrage du projet ?
Parce que corriger après coûte plus cher
Une exigence de sécurité définie au cadrage se chiffre en heures de conception. La même exigence découverte en recette, ou pire en production, se paie en re-développement, en retard de mise en service, parfois en incident. Plus la faille est détectée tard, plus la facture monte.
Parce que le SI bouge en permanence
Une analyse de risques fournit une photo du SI à un instant T. Or chaque projet modifie ce SI : nouveaux flux, nouveaux accès, nouveaux prestataires. Sans démarche ISP, chaque évolution peut éroder le niveau de sécurité sans que personne ne le mesure.
Parce que la conformité ne se rattrape pas
RGPD, ISO 27001, NIS 2, DORA : les référentiels exigent une sécurité maintenue dans le temps, pas un audit ponctuel. Intégrer les exigences au fil des projets évite l’effet tunnel des mises en conformité rétroactives, longues et coûteuses.
La démarche ISP pas à pas
La méthode se cale sur les jalons du projet. Elle se déroule en sept temps.
1. Cadrage et lancement
On définit le périmètre, les acteurs et le niveau d’exigence. Un projet de site vitrine et une migration d’ERP ne justifient pas le même effort : la démarche se proportionne à la sensibilité du projet.
2. Analyse des risques du projet
On identifie les risques propres au projet et les besoins de sécurité et de protection des données associés : données traitées, exposition, interconnexions, tiers impliqués.
3. Définition des mesures de sécurité
Les risques identifiés se traduisent en mesures concrètes : authentification, chiffrement, cloisonnement, journalisation, clauses contractuelles pour les sous-traitants. Ces exigences entrent dans les spécifications du projet.
4. Accompagnement de la mise en place
Les équipes projet ne sont pas laissées seules avec une liste d’exigences : la démarche prévoit un appui à l’implémentation, pour arbitrer quand une mesure entre en tension avec le planning ou le budget.
5. Recette sécurité
Avant la mise en production, on vérifie que les mesures prévues sont bien en place et efficaces. Selon les enjeux, cette recette va de la revue de configuration au test d’intrusion complet.
6. Mise en production accompagnée
Le passage en production est encadré : gestion des comptes et des accès, durcissement, supervision. C’est le moment où les écarts de dernière minute apparaissent.
7. Transition au support et clôture
La sécurité du projet bascule dans le régime courant : qui surveille, qui patche, qui gère les incidents. La démarche ISP se clôt quand le maintien en condition de sécurité est organisé.
Qui fait quoi dans une démarche ISP ?
L’ISP est une démarche d’équipe, pas une affaire de spécialistes isolés.
Le RSSI (ou la DSI) fixe le référentiel d’exigences et arbitre les risques résiduels. Le chef de projet intègre les jalons sécurité dans son planning, comme n’importe quel autre lot. Les équipes métier expriment la sensibilité réelle des données et des usages. Le développement et l’infrastructure implémentent les mesures.
Quand les ressources internes manquent, un prestataire spécialisé porte la méthode : il anime le cadrage, conduit l’analyse de risques, suit les mesures et réalise la recette sécurité. L’essentiel est que la responsabilité de chaque étape soit posée dès le lancement.
Les pièges qui font échouer une démarche ISP
Quatre écueils reviennent dans la plupart des démarches qui déraillent.
La sécurité convoquée en fin de projet : le volet sécurité arrive à la recette, tout est déjà construit, chaque exigence devient un conflit. La démarche perd sa raison d’être.
Les exigences génériques : un référentiel copié-collé, identique pour tous les projets, produit des dizaines de mesures hors sujet. Les équipes décrochent. Les exigences doivent découler de l’analyse de risques du projet, pas d’un catalogue.
La recette sécurité sacrifiée : sous pression de la date de mise en service, la vérification finale saute. Les mesures existent sur le papier, personne n’a contrôlé leur efficacité.
La lourdeur uniforme : imposer la démarche complète au moindre petit projet la discrédite. Un filtrage initial par sensibilité permet de concentrer l’effort là où il compte.
Industrialiser l’ISP : référentiel, méthode, outillage
Une démarche ISP qui repose sur la bonne volonté d’une personne ne survit pas à son départ. Pour durer, elle s’industrialise.
D’abord un référentiel d’exigences de sécurité propre à l’organisation, aligné sur sa politique de sécurité et ses obligations réglementaires. Ensuite l’ancrage dans la méthodologie projet existante : les jalons sécurité s’insèrent dans les instances déjà en place, pas dans un circuit parallèle. Enfin l’outillage : le suivi des exigences, des mesures et des recettes se digitalise pour donner une vision consolidée de l’état de sécurité des projets.
C’est ce que propose Digitemis dans son accompagnement à l’intégration de la sécurité dans les projets, avec une digitalisation possible du processus via la solution Make IT Safe.
À quels projets appliquer la démarche ?
Tout projet qui touche au système d’information est candidat : une migration cloud, une nouvelle application métier, l’arrivée d’un SaaS, une interconnexion avec un partenaire, une refonte d’infrastructure. Chacun modifie la surface d’exposition, les flux de données ou les accès.
Tout n’exige pas le même effort pour autant. Un filtrage initial classe les projets par sensibilité : données traitées, exposition sur internet, criticité métier, tiers impliqués. Les projets à faible enjeu passent par une version allégée de la démarche ; les projets sensibles déroulent la méthode complète. C’est ce tri qui rend l’ISP soutenable dans la durée.
Quels livrables attendre d’une démarche ISP ?
Chaque étape de la méthode produit une trace concrète. Typiquement :
- une note de cadrage qui fixe le périmètre, les acteurs et le niveau d’exigence ;
- l’analyse de risques du projet, avec les besoins de sécurité et de protection des données identifiés ;
- la liste des mesures de sécurité à intégrer aux spécifications, avec leurs responsables ;
- le rapport de recette sécurité, qui atteste que les mesures prévues sont en place et efficaces ;
- les éléments de mise en production : comptes, accès, durcissement, supervision ;
- un bilan de clôture qui organise le transfert au support et le maintien en condition de sécurité.
Ces livrables ont une seconde vie : ils alimentent les audits, les dossiers de conformité et les réponses aux questionnaires de sécurité des clients.
ISP, security by design, privacy by design : comment ça s’articule ?
Les trois notions s’emboîtent. Le security by design est le principe : concevoir sécurisé plutôt que corriger après. L’ISP est sa mise en œuvre concrète, projet par projet, avec des jalons et des livrables.
Le privacy by design en est le pendant pour les données personnelles, et lui n’est pas optionnel : l’article 25 du RGPD impose la protection des données dès la conception et par défaut. Dès qu’un projet traite des données personnelles, l’analyse de risques de l’ISP intègre donc ce volet : minimisation des données, durées de conservation, droits des personnes, sous-traitants.
En pratique, une même démarche projet instruit les deux dimensions. C’est plus efficace que deux circuits parallèles, et c’est ce qui évite qu’un projet conforme côté cyber se fasse rattraper côté RGPD, ou l’inverse.
FAQ
L’ISP est-elle obligatoire ?
Pas en tant que telle : aucun texte n’impose « une démarche ISP ». Mais l’article 25 du RGPD impose la protection des données dès la conception pour tout traitement de données personnelles, et les référentiels comme ISO 27001, NIS 2 ou DORA attendent une gestion des risques qui couvre les évolutions du SI. L’ISP est le moyen le plus direct de tenir ces exigences projet après projet.
Quelle différence entre une ISP et un audit de sécurité ?
L’audit évalue un existant à un instant donné ; l’ISP accompagne une construction du début à la fin. Les deux se complètent : la recette sécurité d’une démarche ISP peut d’ailleurs inclure un test d’intrusion avant la mise en production.
L’ISP ralentit-elle les projets ?
C’est l’inverse qui se vérifie : ce qui retarde un projet, c’est l’exigence de sécurité découverte en recette, quand tout est déjà construit. Posées au cadrage, les exigences se traitent comme n’importe quelle spécification, sans reprise tardive.
Qui doit porter la démarche ?
Un sponsor côté RSSI ou DSI, qui fixe le référentiel et arbitre les risques, et un relais côté chef de projet, qui intègre les jalons sécurité au planning. Sans ce binôme, la démarche reste théorique.
L’essentiel
L’ISP n’est pas une contrainte de plus sur les projets : c’est ce qui évite de payer deux fois, une fois pour construire, une fois pour corriger. La sécurité entre au cadrage, se traduit en exigences proportionnées, se vérifie en recette et se transmet au support. Les organisations qui l’ont adoptée ne reviennent pas en arrière : moins de retouches, une conformité qui suit le rythme des projets et des mises en production sans mauvaise surprise.