L'OWASP propose un top 10 des risques et vulnérabilités sur les LLM et les genIA en général. L'OWASP confirme que l'IA est loin d'être sécurisée, au contraire, les risques de sécurité se multiplient si l'implémentation est mal faite ou l'usage mal cadré. 

1 - injection : le prompt injection est un classique. Un prompt altère le fonctionnement prévu de la genIA et/ du LLM. Et peu à peu on influence son fonctionnement et on amène à générer des données sensibles ou des exemples d'attaque ou des réponses non prévues. Voir : jailbreaking LLM

2 - des données sensibles sont accessibles : trop d'entreprises laissent des données sensibles / privées sur les LLM. Ces données peuvent être accessibles. Il ne faut pas autoriser les LLM / genIA à accéder à ces données sauf dans un cadre strictement interne et déconnecté de l'extérieur

3 - les chaînes LLM constituent un risque et une surface d'attaque potentielle. Risque de corrompre les modèles ou les données, utiliser des API, des services non sécurisés

4 - données et modèles empoisonnés : cela signifie que les données ne sont pas qualifiés ou corrompues. Si ces données ne sont pas bonnes, le LLM sera biaisé et générera de fausses informations et de mauvaises réponses = déviance du modèle. Il faut vérifier l'origine des données et la conformité de celles-ci avec ce que l'on veut générer. Il faut aussi que le LLM soit bien défini et cadré.

5 - La gestion incorrecte des sorties fait spécifiquement référence à une validation et une gestion insuffisantes des sorties générées par le LLM. Et cela peut se propager et corrompre d'autres systèmes

6 - Trop d'agent IA peut nuire à la sécurité et au bon comportement. Avec les agents on peut perdre le contrôle de ce qu'il se passe et favoriser l'hallunication. La qualité médiocre d'un LLM est exploitée. L'agent ou la genIA ne fait pas la différence entre un bon LLM et un mauvais LLM

7 - Fuite au niveau du prompt : il ne faut pas que des identifications, des secrets ou données sensibles se retrouvent dans les réponses du prompt. Il doit "comprendre" ce qui peut être généré ou non. 

8 - Une mauvaise intégration peut être une source de vulnérabilités. Cela peut être accentué en utilisant du RAG.

9 - désinformation : finalement c'est une combinaison des précédents points

10 - consommation illimitée : on n'y pense pas forcément car un déni de services peut impacter un service IA, un genIA en le saturant de prompts qui va alors peser sur l'infrastructure. Cela peut être possible avec des prompts nombreux et longs, des requêtes envoyées en grande quantité dans un délai très court, des API mal limitées pouvant faire exploser les ressources, etc. 

Cette chronique a été générée par ChatGPT :-)

En 2025, le développement logiciel vit une accélération sans précédent de ses paradigmes. Porté par l’IA générative, le cloud natif et une complexification croissante des architectures distribuées, le métier de développeur exige une montée en compétence continue et une compréhension fine des systèmes. Tour d’horizon des tendances techniques qui façonnent l’ingénierie logicielle moderne.

1. IA générative : du pair programming à l’auto-complétion contextuelle

L’intégration de LLMs (Large Language Models) dans les IDE n’est plus anecdotique. GitHub Copilot, CodiumAI, ou les extensions JetBrains avec modèles embarqués permettent aujourd’hui de générer du code à partir de prompts en langage naturel, de rédiger des tests unitaires avec couverture contextuelle, voire de refactoriser en continu. L’usage devient productif dès lors que le développeur garde une posture critique. L’enjeu n’est pas la génération, mais la vérification : typage strict, tests automatisés, et revue de code deviennent des garde-fous indispensables.

2. Évolution des architectures : microservices, DDD et event-driven

Les monolithes cèdent définitivement la place aux architectures distribuées. Les microservices, souvent couplés à une approche Domain-Driven Design (DDD), permettent une granularité fonctionnelle mieux alignée sur les besoins métier. La montée des architectures event-driven avec Kafka, NATS ou RabbitMQ transforme les systèmes en ensembles loosely coupled mais fortement cohérents. Les problématiques de traçabilité (observabilité distribuée), de transactions (sagas, CQRS) et de résilience (circuit breakers, retries) sont désormais au cœur du code métier.

3. Cloud natif, Infrastructure-as-Code et GitOps

Le « cloud native » n’est plus un luxe mais un prérequis. Kubernetes s’est imposé comme l’orchestrateur de référence, avec Helm, ArgoCD et Terraform comme standards pour le déploiement. Les pratiques GitOps permettent de versionner non seulement le code applicatif, mais aussi l’état de l’infrastructure. Cela implique une culture du "code as policy" : les environnements sont reproduits de manière déclarative, et les rollbacks sont aussi simples qu’un git revert. Le développeur devient ainsi un acteur direct de l'infrastructure.

4. DevSecOps, CI/CD et qualité continue

L'automatisation est totale : chaque commit déclenche une pipeline CI, avec build, tests, analyse statique (SonarQube, Semgrep), et éventuellement un scan de vulnérabilités (Snyk, Trivy). Le déploiement continu (CD) via des stratégies comme blue/green ou canary release devient la norme, soutenu par des outils comme FluxCD ou Spinnaker. La sécurité (DevSecOps) s’intègre dès le début : secrets chiffrés dans Vault, politiques réseau via OPA/Gatekeeper, et contrôle d’accès fin (RBAC) sur les clusters.

5. Sobriété et performance : retour à l’essentiel

Le coût environnemental et économique du cloud pousse à une optimisation plus fine : choix de langages plus performants (Rust, Go), réduction des dépendances, optimisation du cold start en serverless, et profilage mémoire/CPU dès le développement. Le GreenOps complète le FinOps dans les équipes techniques, avec des métriques d’empreinte carbone intégrées aux dashboards.

Conclusion : ingénieur full-stack ou full-cycle ?

Le développeur de 2025 n’est plus seulement un producteur de fonctionnalités, mais un artisan de la résilience, de la scalabilité et de la sécurité. La frontière entre dev, ops et security s’estompe, au profit d’équipes autonomes, outillées, et responsables de bout en bout. La dette technique n’est plus tolérée ; la qualité devient un impératif. Plus que jamais, coder, c’est concevoir des systèmes vivants, robustes et intelligents.

14 mois après avoir tourné le dos à l'open source en changer de licence, Redis redevient Open Source. Il faut dire que cette décision avait provoqué la colère de la communauté et des forks étaient nés. Redis change donc d'avis en prenant une licence AGPLv3. 

Pour expliquer ce revirement, Redit explique "...nous avons décidé, en mars 2024, de migrer Redis vers la licence SSPL. Notre objectif a été atteint (AWS et Google maintiennent désormais leur propre fork), mais ce changement a fragilisé nos relations avec la communauté Redis. SSPL n'est pas véritablement open source, car l'Open Source Initiative a précisé qu'elle ne remplissait pas les conditions requises pour être une licence approuvée par l'OSI." Mea culpa mais pas trop.

Ensuite il y a eu des changements dans l'équipe à l'automne 2024 pour préparer la version 8. Et c'est là que le changement de licence s'est imposée : AGPL. Synk présente cette licence ainsi : "dans le cadre de la licence GPLv3, la Free Software Foundation (FSF) a fourni deux types de licences supplémentaires : la licence publique générale limitée (LGPLv3) et la licence publique générale Affero (AGPLv3). La version AGPL de la licence publique générale vise à appliquer des droits de copyleft complets à tous les logiciels qui l’utilisent. Avec la licence AGPL, les équipes des logiciels peuvent s’assurer que toutes les modifications apportées à la base de code sont mises à la disposition du public, même pour les applications côté serveur."

Ainsi si un éditeur, un développeur, un fournisseur cloud ajoute des fonctionnalités à Redis, il devrait ouvrir le code. S'il ne souhaite pas le faire, il pourrait prendre la licence commerciale. 

Annonce : https://redis.io/blog/agplv3/

Drupal se prépare à ouvrir les tests de la 11.2 avec l'alpha 1 disponible le 7 mai prochain. Il s'agit d'une version mineure. La priorité est donnée à la correction de bugs. Les développeurs peuvent déjà testés mais pas en production.

Les points déjà connus :

- patch de sécurité

- bug fix des versions précédentes

- les évolutions et nouveautés seront fixées dans la RC prévue sans la semaine du 2 juin

Les patchs de sécurité des versions 10.3.x, 11.0.x et 10.4.x et 11.1.x seront assurés jusqu'au 18 juin et 10 décembre.

Annonce : https://www.drupal.org/about/core/blog/drupal-112-alpha-phase-begins-may-7