Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA

Florent Mauzé, Country manager France de Checkmarx a accepté de partager son point de vue et son analyse.

Dans les environnements modernes, les équipes travaillent déjà avec des méthodes agiles et des chaînes CI/CD qui permettent de concevoir, tester et déployer en continu. L’intégration d’outils d’IA générative dans ces workflows – souvent directement dans les plateformes de développement, comme avec GitHub Copilot, accélère encore ce mouvement. Pour les développeurs, ces outils sont devenus des assistants quotidiens.

Mais le gain de vitesse a un revers. Le code généré peut introduire des vulnérabilités, intégrer des dépendances peu sûres ou proposer des implémentations qui fonctionnent… sans être forcément robustes du point de vue de la sécurité. Une routine d’authentification trop simplifiée, une bibliothèque mal vérifiée ou une dépendance vulnérable peuvent passer inaperçues si personne ne prend le temps de regarder ce qui se cache derrière la suggestion.

À cela s’ajoutent d’autres risques plus récents : manipulation de modèles via des prompts malveillants, exposition involontaire de clés API ou utilisation d’API externes qui multiplient les points d’exposition. Sans oublier un point souvent sous-estimé : l’usage de ces outils implique fréquemment des traitements dans le cloud, avec un risque d’exposition de données sensibles. Pour les organisations, cela pose aussi un problème de gouvernance. L’IA générative est parfois utilisée de manière informelle par les équipes, en dehors des outils officiellement validés. On voit ainsi apparaître des services ou des API non référencés, une forme « d’IA fantôme » qui échappe aux politiques de sécurité existantes. Et dans beaucoup d’entreprises, les outils AppSec actuels n’ont pas encore complètement intégré ces nouveaux usages.

Sur le terrain, la sécurité, un compromis permanent

Les principes de la sécurité applicative sont clairs et les outils existent — analyse statique, tests dynamiques, contrôle des dépendances, scans de vulnérabilités — mais leur intégration dans le développement reste inégale. Sur le terrain, IT, AppSec et DevOps travaillent sous contraintes : roadmaps rapides, objectifs commerciaux pressants, arbitrages budgétaires constants. La sécurité doit s’insérer sans ralentir les équipes, mais les fondamentaux sont souvent mal maîtrisés. Certains outils sont déployés tardivement ou produisent trop d’alertes, ignorées par les équipes.

Finalement, la posture de sécurité dépend moins de la technologie que de la rigueur sur les bases. La rapidité de mise en production reste le critère dominant, et la sécurité, même stratégique, est encore souvent en concurrence avec les impératifs business, reflétant un arbitrage permanent entre performance immédiate et résilience à long terme.

Florent Mauzé, Country manager France de Checkmarx

Une responsabilité qui devient collective

Un changement important est toutefois en train de s’opérer. La sécurité n’est plus uniquement l’affaire d’une équipe spécialisée. Dans les organisations qui avancent le plus vite sur ces sujets, la sécurité du code devient progressivement une responsabilité partagée. Les développeurs, les équipes DevOps et les responsables techniques participent davantage aux décisions qui touchent à la sécurité des applications. Cette évolution s’inscrit dans la logique du shift left, qui consiste à intégrer la sécurité dès les premières étapes du développement. Elle va parfois encore plus loin : les équipes techniques sont aussi associées aux choix d’outils et aux décisions budgétaires. 65 % des équipes de développement recommandent des produits de sécurité, et 59 % identifient les besoins réels avant tout déploiement.

Cette implication croissante traduit une transformation profonde : les développeurs ne sont plus de simples exécutants, mais de véritables parties prenantes dans la gouvernance de la sécurité applicative. Ils deviennent des acteurs capables de peser sur les arbitrages technologiques et budgétaires, et donc de façonner la posture de sécurité globale de l’entreprise. Plutôt que d’imposer des solutions depuis l’extérieur, il s’agit de choisir des outils qui s’intègrent réellement dans les workflows des développeurs et qui apportent un retour utile au bon moment. Des outils adoptés par les équipes produisent toujours plus d’effet que des solutions théoriquement puissantes mais contournées dans la pratique. Cette dynamique mérite cependant d’être interrogée : le shift left est souvent présenté comme une évidence positive, mais reporter la responsabilité sécurité sur les développeurs sans les former sérieusement, ni les équiper d’outils adaptés, c’est déplacer la charge, pas résoudre le problème.

L’enjeu reste donc humain et organisationnel : faire en sorte que les développeurs considèrent la sécurité comme une compétence à part entière, et non comme une contrainte extérieure. L’essor de l’IA générative rend cette exigence encore plus pressante. Lorsqu’une suggestion d’outil comme GitHub Copilot est acceptée sans en mesurer les implications de sécurité, aucun scanner en fin de chaîne ne peut compenser ce manque de discernement. La réponse passe donc par la formation, par des boucles de feedback rapides directement dans l’IDE et par une culture où signaler une vulnérabilité est perçu comme une amélioration du produit. Sur le plan budgétaire et organisationnel, le défi consiste moins à multiplier les outils qu’à privilégier ceux qui sont réellement adoptés et capables de produire des alertes exploitables. La question de la consolidation des outils de sécurité devient d’ailleurs de plus en plus centrale dans les arbitrages : gérer une mosaïque de solutions ponctuelles génère des coûts cachés — licences multiples, alertes contradictoires à corréler manuellement, courbes d’apprentissage démultipliées.

À budget constant, une approche intégrée permet souvent de détecter les vulnérabilités plus tôt, là où elles coûtent le moins cher à corriger. Enfin, adapter la sécurité à l’ère de l’IA suppose aussi des choix de gouvernance clairs : quels outils sont autorisés, dans quels contextes et selon quelles règles de gestion des données.

Alors que l’IA transforme la manière dont le code est écrit et déployé, la prochaine frontière sera celle de la sécurité agentique : des capacités autonomes, intégrées directement dans les pipelines de développement, capables de détecter, prioriser et proposer des correctifs sans friction. Pour que la sécurité cesse d’être un frein, elle devra opérer à la même vitesse que l’IA qui produit le code, ouvrant la voie à un développement à la fois rapide et véritablement plus sûr.