Toutes les équipes s'accordent à dire que le développement sécurisé est important. Mais quand il s'agit de la responsabilité ? Soudain, tout le monde se renvoie la balle. Les développeurs pensent que c'est le travail de la Sécurité. Les équipes de sécurité s'attendent à ce que les développeurs écrivent un code plus sûr. DevOps veut juste maintenir le pipeline en vie. Et les managers ? Ils veulent de la sécurité sans ralentir les livraisons.

La vérité est que, le développement logiciel sécurisé n'est pas le travail d'une seule personne, mais celui de tous. Cela signifie définir clairement les rôles, les responsabilités et, surtout, les attentes. Si vous ne maîtrisez pas cette partie, l'ensemble de l'effort SSDLC se transforme en un jeu de reproches au ralenti. Analysons qui est sur le terrain, ce qui les empêche de dormir la nuit et ce qu'ils recherchent vraiment à 2 heures du matin.

Image d'illustration : Description de l'image : Diagramme des rôles d'une équipe de développement interfonctionnelle avec des flèches cartographiant les responsabilités pour le codage sécurisé, les tests, l'outillage et la livraison.

Les acteurs clés : Qui est qui dans l'arène du développement sécurisé

Développeurs : Sur le terrain, à la tâche sur le code, évitant les CVE.

Les développeurs sont au plus près du code et sont souvent les premiers à être blâmés lorsque quelque chose ne fonctionne pas. On attend d'eux qu'ils écrivent du code sécurisé, même s'ils n'ont jamais appris comment faire. Ils sont confrontés à la fatigue des alertes provenant d'outils bruyants et de conseils contradictoires. Ce dont ils ont besoin : des conseils de sécurité intégrés à leur workflow, et non ajoutés après coup.

Ingénieurs DevOps : Maîtres du pipeline, gérant les outils et les configurations Cloud

Le DevOps assure le bon fonctionnement du pipeline et la fluidité des déploiements. Ils gèrent les secrets, l'infra-as-code, les configurations de conteneurs et l'intégration CI/CD. On attend souvent d'eux qu'ils « fassent simplement fonctionner la sécurité » sur l'ensemble de la stack, sans casser le build. Ce dont ils ont besoin : une sécurité qui s'intègre à l'automatisation existante, et non des étapes manuelles supplémentaires.

Ingénieurs en sécurité (AppSec/Sécurité Produit) : Les guides, les gardiens et parfois les goulots d'étranglement

Les équipes de sécurité rédigent des politiques, choisissent des outils et tentent d'étendre leur influence auprès de dizaines (voire de centaines) de développeurs. Mais elles sont souvent en infériorité numérique, à raison de 100 contre 1. Elles ont besoin d'outils qui réduisent le bruit, mettent en évidence ce qui compte réellement et aident les développeurs à résoudre les problèmes sans un va-et-vient incessant de tickets.

Managers Techniques : Gérer l'ingérable, équilibrer les fonctionnalités et la raison

Les managers naviguent entre vélocité et risque. Ils sont évalués sur les fonctionnalités livrées, mais aussi sur les temps d'arrêt, les incidents et la conformité. Ce ne sont pas des experts en sécurité, mais on attend d'eux qu'ils prennent des décisions qui protègent l'entreprise. Ils ont besoin de visibilité, de métriques et de l'adhésion de toutes les équipes.

Ce qui les préoccupe le plus

Pour les développeurs : "Sécurité vs Vitesse", L'enfer des outils (Tellement d'alertes), Syndrome du "Ce n'est pas mon travail"

Les développeurs craignent les outils qui bloquent les déploiements et les inondent de problèmes de faible priorité. Ils veulent des retours rapides et exploitables, de préférence dans leur IDE ou leurs PRs. Ils détestent tout ce qui ressemble à un reproche sans soutien.

Pour le DevOps : Goulots d'étranglement des pipelines, Cauchemars de configuration, La gestion des secrets

Le DevOps souhaite moins d'étapes manuelles et moins de surprises. Ils s'inquiètent de pousser accidentellement des données sensibles ou d'exposer un bucket S3 au monde entier. Ils ont besoin de politiques claires et d'outils qui ne compromettent pas l'automatisation.

Pour les professionnels de la sécurité : Trop de bruit, trop peu de ressources, toujours en train de rattraper le retard

Les équipes de sécurité sont submergées par les alertes, les faux positifs et la prolifération d'outils. Elles sont lassées d'être réactives. Ce qu'elles désirent, c'est du contexte, de la priorisation et des moyens d'anticiper les risques, sans devoir surveiller chaque déploiement.

Pour les managers : Justifier les coûts, Gérer les risques, Trouver des personnes qui comprennent ces enjeux

Les managers s'inquiètent du ROI. Cet outil de sécurité en vaut-il la peine ? L'équipe l'utilise-t-elle vraiment ? Ils sont également confrontés à la difficulté de recruter des ingénieurs « licornes » qui maîtrisent à la fois le code et la sécurité. Ils veulent des victoires concrètes, pas un autre tableau de bord à gérer.

Ce qu'ils recherchent réellement sur Google (et ce à quoi ce hub répondra)

Requêtes des développeurs

• "codage sécurisé [ma langue]"
• « Comment arrêter rapidement les injections SQL »
• "Le Top 10 OWASP expliqué pour les humains"

Les développeurs veulent des réponses claires et pratiques. Ils ne cherchent pas des PDF de 80 pages, mais des solutions à copier-coller et des conseils de codage sécurisé spécifiques au langage.

Requêtes DevOps

• "automatiser la sécurité dans le CI/CD sans tout casser" 
• "Outils de scan de sécurité Terraform" 
• "Bonnes pratiques de sécurité Docker qui ne datent pas de 2015"

Le DevOps cherche des moyens d'intégrer la sécurité dans les outils qu'il utilise déjà, sans casser les déploiements ni ralentir les builds.

Requêtes de sécurité :

• "Guide d'implémentation SSDLC pour l'agile"
• une modélisation des menaces que les développeurs apprécieront
• Comparaison des outils SAST

Les ingénieurs en sécurité veulent passer à l'échelle. Ils recherchent des outils et des playbooks qui s'intègrent à l'agilité et aident réellement à « shift left », sans surveillance constante.

Requêtes des Managers : 

• "coût d'une violation de données vs. investissement en sécurité"
• "ROI de la formation en sécurité des développeurs"
• « Comment construire une culture de la sécurité qui ne repose pas sur des exercices de confiance »

Les managers recherchent des chiffres concrets, des investissements justifiables et des méthodes légères pour favoriser un développement sécurisé, sans compromettre la vélocité ou le moral de l'équipe.

Tout le monde veut des logiciels sécurisés. Personne ne veut plus de travail. La clé est de comprendre les points faibles de chaque rôle et de leur fournir des outils et des processus qui fonctionnent avec leur flux de travail, et non contre. 

Il est temps de décortiquer ce qui motive réellement les équipes à adopter des pratiques sécurisées, et ce qui y fait généralement obstacle.