Politique de développement externalisé

La Politique de développement externalisé (P28) établit un cadre complet pour gérer de manière sécurisée les projets de développement de logiciels ou de systèmes exécutés par des fournisseurs externes, des contractants ou des agences. Son objectif principal est d’intégrer des contrôles de sécurité et des mécanismes de gouvernance tout au long du cycle de vie du développement, de la planification et de la négociation contractuelle jusqu’à la livraison, la surveillance et les activités post-engagement. En imposant un ensemble clairement défini d’obligations de sécurité — allant des vérifications de diligence raisonnable des fournisseurs et des appréciations des risques à l’application de normes de programmation sécurisée et d’exigences contractuelles — la politique vise à protéger la confidentialité, l’intégrité et la disponibilité de tous les logiciels développés pour l’organisation. Le champ d’application de la politique s’étend à toute initiative de l’entreprise impliquant un développement par des tiers, y compris les applications web et mobiles, les systèmes embarqués, les interfaces de programmation (API), les plateformes internes et commerciales, ainsi que les flux de travail d’automatisation. Elle régit également toute entité externe nécessitant un accès au code source de l’organisation, aux environnements de test ou aux pipelines CI/CD. Les exigences s’appliquent indépendamment du lieu ou du mode d’exploitation du fournisseur, afin que les distinctions géographiques ou contractuelles ne créent pas de lacunes de sécurité. Les objectifs de la politique reposent sur la réduction de l’exposition aux menaces de la chaîne d’approvisionnement, à la non-conformité juridique (par exemple au GDPR ou à DORA), au vol de propriété intellectuelle et aux pratiques de programmation non sécurisée susceptibles d’introduire des vulnérabilités ou un risque réglementaire. Pour y parvenir, elle attribue des responsabilités explicites à la Direction, au Responsable de la sécurité des systèmes d’information (RSSI), aux équipes Achats et Juridique et conformité, aux propriétaires de projet et de produit, à l’Équipe de sécurité de l’information et aux fournisseurs externes. Au cœur de cette approche se trouve le Registre de développement par des tiers, source unique de vérité pour l’ensemble des engagements fournisseurs, les constatations de diligence raisonnable des fournisseurs, les registres des dérogations aux politiques et les statuts contractuels. Les exigences de gouvernance incluent la diligence raisonnable des fournisseurs, une appréciation des risques de sécurité et un ensemble minimal de contrôles contractuels, tels que l’adhésion à des cadres de programmation sécurisée, les tests de sécurité, les spécifications de propriété de la PI, l’exécution d’un accord de non-divulgation et des clauses de droit d'audit. Le code source est géré exclusivement via des plateformes contrôlées par l’entreprise, avec protection des branches, évaluation par les pairs et protocoles stricts de procédure de départ afin d’éviter les fuites de code ou la réutilisation non autorisée. Tout accès des tiers est provisionné selon une gouvernance des accès limitée dans le temps et conforme au principe du moindre privilège, surveillé via des journaux d'audit et rapidement révoqué à la clôture de l’engagement. L’intégration des dépôts fournisseurs dans les outils de sécurité de l’entreprise pour l’analyse de code, la mise en application des politiques CI/CD et la gestion des exceptions est requise chaque fois que cela est possible. Les demandes de dérogation sont traitées via un processus formel de traitement des risques et d’approbation piloté par le Responsable de la sécurité des systèmes d’information (RSSI), incluant la documentation de la justification, des mesures d’atténuation et des délais de remédiation. L’Équipe de sécurité de l’information réalise une surveillance continue et des audits de conformité, les violations pouvant entraîner une révocation des accès immédiate, la suspension du projet, une action en justice ou des mesures disciplinaires selon le cas. Cette politique est revue au moins annuellement ou à la suite de changements du contexte réglementaire, de résultats de réponse aux incidents ou de sorties d’audit interne. Toutes les modifications sont gérées via des systèmes de gestion de versions, communiquées et référencées dans la documentation procédurale. Grâce à ces mécanismes et à son alignement avec les principales normes internationales et obligations légales, la Politique de développement externalisé garantit que la livraison logicielle par des tiers demeure sécurisée et conforme, protégeant l’organisation contre l’évolution des risques liés au développement externalisé.