90 % d’économies avec 5 lignes de code!

L'IA dans SecDevOps: pourquoi les "hacks de coûts" ne sont pas toute l'histoire

Je lisais un article de towardsdatascience.com. Et il m'est venu à l'esprit que la plupart d'entre nous seraient tentés de se lancer dans cette situation à l'aveuglette. Voici mon point de vue, sur ce qui en est.

"Comment nous avons réduit les coûts de LLM de 90% avec 5 lignes de code". À première vue, ce genre d'histoire est captivant: cinq lignes de code, 90% d'économies, comment ne pas adorer?

Mais lorsque nous regardons les choses à travers le prisme de SecDevOps, le récit devient plus complexe. Le coût n'est pas la seule variable qui compte dans une pratique sûre, résiliente et fiable.

*L'image est générée par l'IA

La tentation des solutions rapides

L'article décrit comment les développeurs ont utilisé la troncage de "réponse" avec leurs modèles de langage à grande échelle (LLM) pour réduire l'utilisation des jetons et réduire les coûts. Cela fonctionne bien dans les expériences à portée étroite ou les POC (preuves de concept). Mais dans les environnements SecDevOps: où les systèmes de production gèrent des flux de travail critiques pour la sécurité : les gains rapides s'accompagnent souvent de risques cachés :

• Angles morts opérationnels: Tronquer les réponses du modèle peut réduire les coûts, mais cela risque également de supprimer le contexte, les journaux ou les alertes de sécurité essentiels.
• Les LLM dans les pipelines d'opérations de sécurité peuvent gérer la télémétrie sensible. Toute stratégie d'optimisation doit être validée par rapport à la confidentialité des données et à la conformité réglementaire.
• Que se passe-t-il si une optimisation interrompt silencieusement un flux de travail de réponse aux incidents à 2 h du matin?

En bref: épargner 90% aujourd'hui ne signifie pas grand-chose si vous compromettez 99% de la confiance du système demain.

La perspective de SecDevOps

Lorsque nous introduisons des outils d'IA dans nos pipelines, que ce soit pour le triage des journaux, l'analyse de code ou l'aide à la décision en matière de sécurité, nous devons appliquer la même rigueur que nous apportons à toute autre technologie. 

Quelques principes directeurs :

• Des mesures holistiques, pas seulement des coûts.
  Mesurez non seulement les économies d'argent, mais aussi l'exactitude de la réponse, la couverture de détection, le respect de la conformité et le temps de récupération des incidents.

• Dépendances de l'IA de modélisation des menaces
  Chaque "optimisation" devient une nouvelle surface d'attaque. Par exemple: un attaquant pourrait-il exploiter la troncature de sortie pour cacher une activité malveillante dans les journaux?

• Déploiement contrôlé
  Les techniques d'économie de coûts doivent d'abord être déployées dans des environnements non liés à la production (Dev > QA > Acceptance) avant d'atteindre la production: le même chemin discipliné que nous utilisons pour toute migration d'infrastructure en tant que code ou de base de données.

• Vérifiabilité par défaut
  Nous ne nous contentons pas d'optimiser; nous documentons. Chaque changement dans la façon dont l'IA est utilisée dans les pipelines doit être vérifiable, versionné et sujet à annulation.

Application pratique dans les pipelines

Chez JPSoftworks, voici comment nous intégrerions une telle technique en toute sécurité dans un pipeline de sécurité CI/CD :

1. Isoler les composants d'IA dans les services dockerisés 
    Assurez-vous que les demandes et les réponses de LLM sont transmises par un conteneur de services avec des limites, une journalisation et une surveillance appliquées.

2. Contrôle centralisé des politiques
   Utilisez IaC (Bicep, Terraform) pour définir des politiques autour de l'interaction LLM: ycompris la troncature maximale des jetons et les catégories de données autorisées.

3. Couche de vérification
   Introduire des étapes de validation (p. ex., somme de contrôle, vérifications d'exhaustivité basées sur les regex) avant que les systèmes en aval ne consomment la sortie du modèle tronqué.

Conclusion: Au-delà des 5 lignes de code

Les articles promettant des "économies de 90%" attirent l'attention: et ils devraient. Les coûts sont importants. Mais dans SecDevOps, le coût ne peut jamais être le seul axe d'optimisation. La sécurité, la fiabilité et la vérifiabilité doivent être de pair avec l'efficacité.

Chez JPSoftworks, nous croyons qu'il est important de permettre aux organisations d'adopter l'innovation sans compromettre la confiance. Les gains rapides sont les bienvenus, mais seulement lorsqu'ils sont bien intégrés dans les systèmes sécurisés et résilients qui assurent le fonctionnement des entreprises.

Liens (Anglais):
How We Reduced LLM Costs by 90% with 5 Lines of Code | Towards Data Science

Saving 90% of cost with five lines of code.

 

AI in SecDevOps: Why “Cost Hacks” Aren't the Whole Story

I was just reading an article by towardsdatascience.com. And it occurred to me that most of us would be tempted to jump into this pretty blindly. Here's my take on it.

“How We Reduced LLM Cost by 90% with 5 Lines of Code”. On the surface, this kind of story is exciting: five lines of code, 90% cost savings, what's not to love?

But when we look at it through the lens of SecDevOps, the narrative becomes more complex. Cost isn't the only variable that matters in a secure, resilient, and reliable practice.

*Picture is AI Generated

---

The Temptation of Quick Fixes

The article describes how developers used response truncation with large language models (LLMs) to reduce token usage and slash costs. This works well in narrowly scoped experiments or proof-of-concepts. But in SecDevOps environments: where production systems handle security-critical workflows: quick wins often come with hidden risks:

• Operational Blind Spots: Truncating model responses might cut costs, but it also risks cutting out essential security context, logs, or alerts.
• LLMs in security operations pipelines may handle sensitive telemetry. Any optimization strategy must be validated against data confidentiality and regulatory compliance.
• What happens if an optimization silently breaks an incident response workflow at 2 a.m.?

In short: saving 90% today means little if you compromise 99% of system trust tomorrow.

---

The SecDevOps Perspective

When we introduce AI tooling into our pipelines: whether for log triage, code analysis, or security decision-support: we must apply the same rigor we bring to any other technology.

Some guiding principles:

• Holistic Metrics, Not Just Cost.
  Measure not only dollar savings, but also response accuracy, detection coverage, compliance adherence, and incident recovery time.

• Threat Modeling AI Dependencies
   Every “optimization” becomes a new attack surface. For example: could an attacker exploit output truncation to hide malicious activity in logs?

• Controlled Deployment
  Cost-saving techniques should first roll out in non-production environments (Dev → QA → Acceptance) before reaching Production: the same disciplined path we use for any infrastructure-as-code or database migration.

• Auditability by Default
  We don't just optimize; we document. Every change in how AI is used within pipelines must be auditable, versioned, and subject to rollback.

---

Practical Application in Pipelines

At JPSoftworks, here's how we would integrate such a technique safely into a CI/CD security pipeline:

1. Isolate AI Components in Dockerized Services
    Ensure LLM requests and responses are mediated through a service container with enforced limits, logging, and monitoring.

2. Centralized Policy Control
   Use IaC (Bicep, Terraform) to define policies around LLM interaction: including max token truncation and allowable data categories.

3. Verification Layer
   Introduce validation steps (e.g., checksum, regex-based completeness checks) before downstream systems consume truncated model output.

---

Conclusion: Beyond the 5 Lines of Code

Articles promising “90% savings” capture attention: and they should. Cost matters. But in SecDevOps, cost can never be the only axis of optimization. Security, reliability, and auditability must stand shoulder to shoulder with efficiency.

At JPSoftworks, we believe in enabling organizations to embrace innovation without compromising trust. Quick wins are welcome: but only when they are integrated thoughtfully into the secure, resilient systems that keep businesses running.

---

Links:
How We Reduced LLM Costs by 90% with 5 Lines of Code | Towards Data Science

EAC or everything as code

 

Everything as Code: The Backbone of a Reliable, Secure, and Consistent DevSecOps Practice

At JPSoftWorks, you know, we've always believed that technology should serve people first: not the other way around. Over the years, working in SecDevOps, one truth has become increasingly clear to us: in order to create secure, maintainable, and high-quality systems, you need uniformity. And uniformity doesn’t happen by accident. It happens because you deliberately build it into your processes.

For us, one of the most powerful enablers of that uniformity is the philosophy of "Everything as Code" (EaC).

This isn’t just a catchy slogan or a trendy buzzword. It’s a disciplined approach that treats every element of your product lifecycle: application code, infrastructure, configurations, policies, pipelines, documentation, and even compliance checks: as version-controlled, reviewable, and testable artifacts.

And when you combine this philosophy with a solid Git-based branching and merging process, you unlock a level of consistency, traceability, and automation that fundamentally changes how you deliver value.

---

What "Everything as Code" Really Means

The simplest way to explain "Everything as Code" is:

If it can be expressed in a file, it belongs in version control. Ideally in a format that is friendly to content compares.

That means:

• Application code: of course, but also…
• Infrastructure as Code (IaC): Bicep, Terraform, ARM templates, Ansible playbooks, etc.
• Configuration as Code (CaC): Kubernetes manifests, application settings, feature flags.
• Policy as Code (PaC): Security and compliance rules, e.g., Open Policy Agent (OPA), Azure Policy definitions.
• Documentation as Code: Markdown, reStructuredText, or AsciiDoc files stored alongside the project.
• Pipeline as Code: CI/CD workflows in YAML (Azure DevOps, GitHub Actions, GitLab CI).
• Test definitions: Unit tests, integration tests, performance tests, and security scans scripts.
• Monitoring and alert definitions: Grafana dashboards, Prometheus rules, Azure Monitor alert definitions.

This approach eliminates the "special snowflake" problem: where production works one way, dev works another, and nobody’s quite sure how staging was set up. When everything lives in Git, there’s a single source of truth.

---

Why Git Is the Glue That Makes It Work

"Everything as Code" is powerful, but it’s not enough on its own. You need a discipline around how changes enter your codebase. That’s where Git, and specifically a deliberate branching and merging strategy, comes in.

We have a simple principle:

No change reaches the main branch without deliberate review and automated verification.

Every update: whether it’s a new feature, a change to infrastructure, a tweak in a policy, or a line in the documentation: comes in via a branch and a pull request (PR). That PR is the checkpoint where we:

1. Review the change: human eyes on the code, by the right people.
2. Run automated checks: tests, security scans, policy validations.
3. Decide deliberately: to merge or not to merge.

It’s not just bureaucracy. This process is where we ensure that changes meet our standards for security, performance, compliance, and maintainability. It's one of the many ways, Security Developers and Operations, joion forces to arrive to a better quality product in record time.

---

Uniformity Through Review and Automation

An here's how it works.

When you have a Git/merge process in place, you build uniformity into your product for developers this has been a "no brainer".

This now becomes a practice spread in four key areas:

1. Product Consistency

Whether it’s application features or bug fixes, PR reviews ensure that:

• New code follows established patterns and coding standards.
• Functionality is consistent with business and user expectations.
• Security implications are addressed before code hits production.

Automated checks here might include:

• Compilation/build validation: make sure the code builds cleanly in a consistent environment.
• Unit tests: catch regressions early.
• Static code analysis: flag potential security vulnerabilities or bad practices (e.g., SonarQube, ESLint, Roslyn analyzers).
• Dependency scanning: identify vulnerable third-party packages.

2. Configuration Uniformity

Configuration drift is one of the biggest headaches in operations. With Configuration as Code:

• Your dev, QA, and production environments are built from the same base files.
• Any change in configuration goes through the same PR process.
• Rollbacks are as simple as reverting a Git commit.

Automated checks might include:

• Linting configuration files: e.g., yamllint, terraform validate.
• Policy compliance: Azure Policy, OPA checks in pipelines.
• Idempotency tests: ensuring rerunning the configuration doesn’t cause unexpected changes.

3. Documentation Alignment

By keeping documentation in the same repo as the code, you eliminate stale, irrelevant, or contradictory docs.

• PR reviewers can check that documentation updates match the actual feature or configuration change.
• Automated processes can even check for broken links or missing sections.
• Tools like mkdocs or Sphinx can automatically rebuild and publish updated documentation.

Automation here could include:

• Spellcheck/grammar check: automated linting for docs.
• Doc coverage checks: ensuring new features have accompanying documentation.
• Link validation: to ensure no outdated references.

4. Test Synchronization

Tests live alongside the code they validate. When you change a feature:

• The PR process requires updating or adding tests.
• Automated CI ensures those tests run on every change.
• Code coverage tools report if coverage has decreased.

This makes it impossible to "forget" to update tests because reviewers will catch it: and the pipeline will fail if the tests don’t pass.

---

The Automation Opportunities in the Merge Process

The pull request process is not just about human review. It’s also the perfect trigger point for automation. Our PR pipelines might run:

• Build & Compile: Verifying the code compiles in a clean environment.
• Unit Tests: Immediate validation of logic.
• Integration Tests: Ensuring services play well together.
• Static Code Analysis: Security and quality gates.
• Dependency Scans: SCA (Software Composition Analysis) to find vulnerable libraries.
• Infrastructure Validation: e.g., terraform plan or Azure ARM/Bicep "What-If".
• Policy Checks: Automated verification of security rules.
• Performance Baselines: Quick checks to ensure we haven’t introduced performance regressions.
• Compliance Verification: Automated SOC 2, ISO 27001, or internal policy checks.
• Container Image Scanning: Detect vulnerabilities in Docker images.
• Secret Detection: Prevent accidental commits of API keys or credentials.

This shift-left automation means issues are caught before they have a chance to impact production.

---

Security as an Embedded Outcome

Because everything goes through version control and PR review, we automatically embed security in the process:

• No undocumented changes: every change is tracked with commit history.
• No unauthorized changes: Git permissions enforce who can merge.
• Transparent audit trail: full visibility into who changed what and why.
• Security scans at PR time: so vulnerabilities are fixed before release.

In traditional environments, security is often a gate at the end of the pipeline. In "Everything as Code," security becomes part of the flow. This one of the key concepts.

---

Real-World Benefits

Implementing "Everything as Code" with disciplined Git processes gives JPSoftWorks and our clients:

• Fewer production incidents: because drift and undocumented changes are eliminated.
• Faster onboarding: new team members have the complete system described in code.
• Simpler audits: compliance evidence is in Git.
• Predictable deployments: what we tested is what we ship.
• Confidence in change: automated checks catch regressions early.

And perhaps the biggest benefit: trust. Teams trust the system because they know changes are deliberate, reviewed, and tested. Stakeholders trust delivery because they see a reliable track record.

---

Going Beyond: Future Opportunities

"Everything as Code" is not static. Here are some additional baby steps worth exploring:

• Automated threat modeling as part of PR pipelines.
• Self-healing infrastructure definitions that are triggered and adapt based on monitored metrics.
• AI-assisted PR reviews to flag potential issues faster.
• Unified observability as code: version-controlling dashboards and alert rules alongside application changes.

---

Conclusion

At JPSoftWorks, "Everything as Code" is more than a technical choice: it’s a cultural one. It says:

• We value transparency.
• We value deliberate change.
• We believe automation should amplify human expertise, not replace it.
• We believe that security, consistency, and quality are built in: not bolted on.

By combining the philosophy of "Everything as Code" with a disciplined Git-based merging process, we ensure that products, configurations, documentation, and tests evolve together: reviewed by the right people and validated by automation before they ever touch production.

That’s how we help create software that doesn’t just work today, but can be trusted tomorrow.

---

If you’d like to see how this approach can strengthen your own delivery processes: and secure them: let’s talk. At JPSoftWorks, we’re here to make tools and technology work for people, first. Contact Us

TEC, ou Tout en (tant que) Code.

 

Le "Tout en Code" : L'épine dorsale d'une pratique SecDevOps fiable, sécurisée et cohérente

Chez JPSoftWorks, vous savez, nous avons toujours cru que la technologie devait servir les gens avant tout : et non l'inverse, et oui on insiste. Grâce à cela, et au fil des années, en travaillant dans le domaine du SecDevOps, une vérité est devenue de plus en plus évidente pour nous: pour créer des systèmes sécurisés, maintenables et de haute qualité, il faut de l'uniformité. Et l'uniformité ne se produit pas par hasard. Elle résulte d'une volonté de l'intégrer délibérément à vos processus.

Pour nous, l'un des leviers les plus puissants pour atteindre cette uniformité est la philosophie du "Tout en Code" (Everything as Code, EaC).

Ce n'est pas qu'un slogan accrocheur ou un terme à la mode. C'est une approche disciplinée qui considère que chaque élément du cycle de vie d'un produit: code applicatif, infrastructure, configurations, politiques, pipelines, documentation, et même contrôles de conformité, doit être un artefact versionné, révisible et testable.

Et lorsque vous combinez cette philosophie avec un processus structuré de ramification et de fusion Git, vous libérez un niveau de cohérence, de traçabilité et d'automatisation qui transforme fondamentalement votre façon de livrer de la valeur.

---

Ce que signifie vraiment "Tout en (tant que) Code"

La manière la plus simple d'expliquer le "Tout en Code" est :

Si cela peut être exprimé dans un fichier, cela doit être placé sous contrôle de version. Idéalement dans un format propice à la comparaison de contenu.

Cela signifie :

• Code applicatif : bien sûr, mais aussi…
• Infrastructure en Code (IaC) : Bicep, Terraform, modèles ARM, playbooks Ansible, etc.
• Configuration en Code (CaC) : manifestes Kubernetes, paramètres applicatifs, indicateurs de fonctionnalités.
• Politiques en Code (PaC) : règles de sécurité et de conformité, ex. Open Policy Agent (OPA), définitions Azure Policy.
• Documentation en Code : fichiers Markdown, reStructuredText ou AsciiDoc stockés avec le projet.
• Pipelines en Code : workflows CI/CD en YAML (Azure DevOps, GitHub Actions, GitLab CI).
• Définitions de tests : tests unitaires, d'intégration, de performance et scripts d'analyses de sécurité.
• Définitions de supervision et d'alertes : tableaux de bord Grafana, règles Prometheus, définitions d'alertes Azure Monitor.

Cette approche élimine le problème du "spécimen unique" : où la production fonctionne d'une manière, le développement d'une autre, et où personne ne sait vraiment comment l'environnement de préproduction a été configuré. Quand tout vit dans Git, il n'existe qu'une seule source de vérité.

---

Pourquoi Git est la colle qui fait tenir le tout

Le "Tout en Code" est puissant, mais ce n'est pas suffisant en soi. Il faut une discipline sur la manière dont les changements entrent dans votre dépôt de code. C'est là que Git, et plus précisément une stratégie réfléchie de branches et de fusions, intervient.

Nous avons un principe simple :

Aucun changement n'atteint la branche principale sans révision délibérée et validation automatisée.

Chaque mise à jour: qu'il s'agisse d'une nouvelle fonctionnalité, d'une modification d'infrastructure, d'un ajustement de politique ou d'une ligne de documentation, passe par une branche et une demande de tirage (Pull Request). Cette PR est le point de contrôle où :

1. Nous révisons le changement : un examen humain, par les bonnes personnes.
2. Nous exécutons des vérifications automatisées : tests, analyses de sécurité, validations de politiques.
3. Nous décidons délibérément : fusionner ou non.

Ce n'est pas de la bureaucratie. Ce processus garantit que les changements respectent nos standards de sécurité, de performance, de conformité et de maintenabilité. C'est l'une des nombreuses façons dont Security, Development et Operations unissent leurs forces pour obtenir un produit de meilleure qualité, en un temps record.

---

L'uniformité grâce à la révision et à l'automatisation

Et voici comment cela fonctionne.

Avec un processus Git/merge bien établi, vous bâtissez l'uniformité au sein de votre produit. Pour les développeurs, c'est devenu une évidence depuis belle lurette.

Cette pratique s'étend désormais à quatre domaines clés :

1. Cohérence du produit

Qu'il s'agisse de fonctionnalités ou de corrections de bogues, les revues de PR garantissent :

• Que le nouveau code suit les standards et modèles établis.
• Que les fonctionnalités sont conformes aux attentes métiers et utilisateurs.
• Que les implications en matière de sécurité sont traitées avant d'atteindre la production.

Vérifications automatisées possibles :

• Validation de compilation/build : s'assurer que le code compile proprement dans un environnement cohérent.
• Tests unitaires : détecter rapidement les régressions.
• Analyse statique du code : signaler les vulnérabilités potentielles ou mauvaises pratiques (SonarQube, ESLint, analyseurs Roslyn).
• Analyse des dépendances : identifier les bibliothèques tierces vulnérables.

2. Uniformité des configurations

La dérive de configuration est un cauchemar récurrent en exploitation. Avec la Configuration en Code :

• Dev, QA et production sont construits à partir des mêmes fichiers de base.
• Tout changement de configuration passe par le même processus de PR.
• Les retours arrière se font simplement via un revert Git.

Vérifications automatisées possibles :

• "Linting" des fichiers de configuration : yamllint, terraform validate, etc.
• Conformité aux politiques : Azure Policy, vérifications OPA.
• Tests d'idempotence : s'assurer que rejouer la configuration ne provoque pas de changements imprévus.

3. Alignement de la documentation

En conservant la documentation dans le même dépôt que le code, on élimine les documents obsolètes ou contradictoires.

• Les réviseurs peuvent vérifier que la documentation reflète bien le changement apporté.
• Des processus automatisés peuvent détecter les liens cassés ou les sections manquantes.
• Des outils comme mkdocs ou Sphinx peuvent reconstruire et publier automatiquement la documentation.

Automatisation possible :

• Vérification orthographique/grammaticale : linting automatisé pour la doc.
• Vérification de couverture documentaire : s'assurer que les nouvelles fonctionnalités sont documentées.
• Validation des liens : éviter les références obsolètes.

4. Synchronisation des tests

Les tests vivent aux côtés du code qu'ils valident. Lorsqu'on modifie une fonctionnalité :

• La PR exige la mise à jour ou l'ajout de tests.
• L'intégration continue exécute ces tests à chaque changement.
• Les outils de couverture signalent toute baisse du taux de couverture.

Impossible donc "d'oublier" de mettre à jour les tests : les réviseurs le verront et la pipeline échouera si les tests ne passent pas.

---

Les opportunités d'automatisation dans le processus de merge

La PR n'est pas qu'une revue humaine. C'est aussi le point de déclenchement idéal pour l'automatisation. Nos pipelines de PR peuvent exécuter :

• Build & Compile : vérifier que le code compile dans un environnement propre.
• Tests unitaires : validation immédiate de la logique.
• Tests d'intégration : garantir l'interopérabilité des services.
• Analyse statique du code : contrôles qualité et sécurité.
• Analyse des dépendances : détection de bibliothèques vulnérables (SCA).
• Validation d'infrastructure : terraform plan ou Azure ARM/Bicep “What-If”.
• Vérifications de politiques : contrôle automatisé des règles de sécurité.
• Tests de performance de référence : détecter les régressions.
• Vérifications de conformité : SOC 2, ISO 27001 ou règles internes.
• Analyse d'images Docker : détection de vulnérabilités.
• Détection de secrets : éviter la publication accidentelle de clés/API.

Cette automatisation shift-left permet de détecter les problèmes avant qu'ils n'affectent la production.

---

La sécurité comme résultat intégré

Parce que tout passe par le contrôle de version et la revue de PR, nous intégrons la sécurité dès le départ :

• Aucun changement non documenté : chaque modification est tracée dans l'historique Git.
• Aucun changement non autorisé : les permissions Git définissent qui peut fusionner.
• Traçabilité transparente : visibilité complète sur qui a changé quoi, et pourquoi.
• Analyses de sécurité au moment de la PR : corriger les vulnérabilités avant la mise en production.

Dans les environnements traditionnels, la sécurité est souvent une étape à la fin de la chaîne. Avec le "Tout en Code", elle fait partie intégrante du flux. C'est l'un des concepts clés.

---

Bénéfices concrets

Mettre en place le "Tout en Code" avec un processus Git discipliné apporte à JPSoftWorks et à nos clients :

• Moins d'incidents en production : la dérive et les changements non documentés sont éliminés.
• Intégration plus rapide : les nouveaux membres ont l'ensemble du système décrit dans le code.
• Audits simplifiés : les preuves de conformité sont dans Git.
• Déploiements prévisibles : ce qui est testé est ce qui est livré.
• Confiance dans le changement : les vérifications automatisées détectent les régressions tôt.

Et peut-être le plus grand avantage : la confiance. Les équipes font confiance au système car elles savent que les changements sont délibérés, révisés et testés. Les parties prenantes font confiance aux livraisons, car elles constatent une fiabilité constante.

---

Aller plus loin : perspectives futures

Le "Tout en Code" n'est la fin en soi de SecDevOps. Quelques pistes de "Baby steps" additionnelles à explorer:

• Modélisation automatisée des menaces dans les pipelines de PR.
• Infrastructure auto-réparatrice déclenchée par des métriques de supervision.
• Revue de PR assistée par IA pour signaler plus vite les problèmes potentiels.
• Observabilité unifiée en code : tableaux de bord et alertes versionnés avec les changements applicatifs.

---

Conclusion

Chez JPSoftWorks, le "Tout en Code" est plus qu'un choix technique : c'est un choix culturel. Il exprime que :

• Nous valorisons la transparence.
• Nous valorisons le changement délibéré.
• Nous croyons que l'automatisation doit amplifier l'expertise humaine, pas la remplacer.
• Nous croyons que la sécurité, la cohérence et la qualité sont intégrées : pas ajoutées après coup.

En combinant la philosophie du "Tout en Code" avec un processus de fusion Git discipliné, nous nous assurons que produits, configurations, documentation et tests évoluent ensemble : revus par les bonnes personnes et validés par l'automatisation avant de toucher la production.

C'est ainsi que nous aidons à créer des logiciels qui ne fonctionnent pas seulement aujourd'hui, mais qui seront fiables demain.

---

Si vous souhaitez voir comment cette approche peut renforcer et sécuriser vos processus de livraison, discutons-en. Chez JPSoftWorks, nous faisons en sorte que les outils et la technologie travaillent pour les gens, avant tout. Contactez Nous.

L’excellence en ingénierie est-elle une espèce en voie de disparition?

Une réflexion SecDevOps sur le rapport 2025 "State of Software Engineering Excellence"

---

Pourquoi ce rapport est important pour moi

Si vous suivez mes périples écrits, vous savez que je considère DevOps (et son aîné SecDevOps) comme un sport d'équipe: trouver l'équilibre entre vitesse et sécurité, humanité et processus, durabilité et valeur pour les actionnaires. Lorsque Harness a publié la semaine dernière son étude State of Software Engineering Excellence 2025, j'ai pris un café et dévoré les plus de 30 pages du rapport.

Le constat est brutal: la majorité des organisations n'atteignent toujours pas la cible en matière d'expérience développeur et de maturité DevOps, ce qui se traduit par une productivité en baisse, un risque qui s'envole et des talents frustrés. (harness.io)

---

Aperçu des constats

Point problématique	Données du sondage
Boucles de rétroaction lentes	67 % des équipes n'arrivent pas à mettre en place un environnement complet de build/test en 15 minutes
Tâches manuelles	64 % déploient encore le code infra à la main ; 50 % livrent les applis manuellement
Temps d'attente pour revue de code	61 % attendent plus d'une journée pour une revue
Absence de garde-fous qualité	55 % des pipelines CI/CD n'ont aucun contrôle de passage
Lacunes dans la préparation aux incidents	52 % manquent d'outils clés pour la réponse aux incidents
Angles morts en sécurité	38 % ne scannent pas leurs builds ; 1 équipe sur 10 laisse passer des bogues critiques en prod ; médiane de correction ≥ 7 jours pour les vulnérabilités graves

Ajoutez à cela:

• Seulement 29 % disposent d'un catalogue logiciel à jour.
• À peine 19 % offrent un programme structuré de montée en compétences aux devs.
• Un quart des équipes admet que plus de 70 % des user stories n'ont pas de critères d'acceptation clairs.

Pour le dire bêtement, le moteur DevOps cogne, le témoin moteur clignote et on roule encore à 120 km/h sur la 132.

---

Pourquoi cet écart persiste-t-il?

Dans mes mandats de conseil, je vois trois antipat­terns récurrents:

1. Un DevOps centré sur le rôle: on embauche un"magicien du pipeline"et on espère que la magie se répande.
2. L'obsession"tool-first": on achète les meilleurs gadgets sans toucher aux processus ni à la dynamique d'équipe.
3. Le culte de la vélocité à court terme: on livre des fonctionnalités plus vite aujourd'hui en accumulant la dette technique (et les blessures de stress) pour demain.

Les données Harness confirment les trois: beaucoup d'outils tape-à-l'œil, mais des contrôles manuels ; quelques poches d'excellence, mais zéro ownership transversal ; des ingénieurs héroïques, mais des systèmes fragiles.

---

Les avantages de la trajectoire actuelle (oui, il y en a)

Ce qui fonctionne	Pourquoi c'est quand même positif
La prise de conscience progresse	650 leaders ont pris le temps de s'auto-évaluer: c'est déjà un pas culturel.
La pensée plateforme émerge	Le rapport fait la promotion des plateformes de livraison logicielle unifiées, exactement ce que prône le SecDevOps moderne.
La formation sécurité existe	56 %* forment au moins annuellement leurs devs. Pas parfait, mais c'est une base. (harness.io)
Les métriques supplantent les anecdotes	L'usage d'une grille de maturité fait passer la discussion du "ressenti" à la preuve.

*Note verre à "moitié plein": cela signifie aussi que 44 % forment moins d'une fois par an, voire jamais.

---

Les inconvénients (le vrai centre de coûts)

• Hémorragie de productivité: chaque pause de 30 minutes en attente d'une revue, c'est des intérêts composés de gaspillage.
• Dette de sécurité: une semaine pour patcher une vulnérabilité critique, c'est l'éternité pour un attaquant ; les exploits de chaîne d'approvisionnement n'attendent pas le sprint planning.
• Épuisement des personnes: déploiements manuels et incidents hors heures font naître la fatigue que l'IA promettait d'éliminer.
• Frein à l'innovation: des talents occupés à réparer des pipelines cassés ne créent pas la prochaine fonctionnalité.

Multipliez cela par les salaires mondiaux et vous comprenez les "millions" cités par Harness. (harness.io)

---

Un prisme SecDevOps sur les recommandations

Sans surprise, Harness prône une approche centrée plateforme. Je suis d'accord… avec réserves.

Prescription Harness	Ma bonification SecDevOps
Automatiser les pipelines de bout en bout	Oui, mais le policy-as-code doit verrouiller chaque étape: SAST, SBOM, dérive IaC, scan de secrets, Snyk, SonarQube, & Cie.
Adopter des portails développeur internes (IDP)	Absolument, mais avec des paramètres de moindre privilège par défaut et des garde-fous pour éviter l'infra "clandestin".
Former en continu	Incontournable. Combinez les sessions de code sécuritaire obligatoires à une rotation en gestion d'incident pour développer l'empathie.
Mesurer la maturité sur cinq axes	Faites-le, mais complétez la grille par les métriques DORA pour garder le duo débit, fiabilité et un prisme SevDevOps je vous prie. (wikipedia.org)

---

Le changement culturel prime sur le changement de plateforme

On ne peut pas sécuriser ce qu'on ne comprend pas; on ne peut pas automatiser ce qu'on n'a pas convenu de standardiser. Cela exige:

• Rétrospectives sans blâme et sans filtre: mettre en lumière les frictions derrière ces builds de moins de 15 minutes.
• SLO partagés: dev, ops et sécurité portent la même imputabilité, "MTTR" et taux d'échec de déploiement.
• KPI de durabilité: suivre la charge d'astreinte, les plages hors heures et les heures de formation comme des métriques de première classe. (Voir la recherche émergente sur le Sustainable DevOps: arxiv.org et notre article La pérennité est la nouvelle performance)

---

L'aspect humain : la variable manquante

Le rapport traite de dollars et de défauts. Ajoutons la dimension humaine :

• Travail manuel = épuisement.
• Attente de revue = désengagement.
• Incidents lents = on réveille le même héros à 3 h du matin.

S'attaquer à ces points n'est pas qu'une stratégie de rétention: c'est de la gestion des risques. Un esprit fatigué configure mal, la prod!

---

Mon plan d'action en quatre points

1. Cartographier le gaspillage. Time-in-queue, et non les lignes de code, est mon indicateur phare. Si vos PR stagnent plus de 12 heures, réparez la boucle de feedback avant d'acheter un autre scanner.
2. Déplacer les conversations sécurité à gauche. Les outils détectent des motifs ; les humains jugent la plausibilité. Organisez des"brown-bags"de modélisation des menaces pour que les devs flairent le danger avant la PR.
3. Investir autant dans la plateforme que dans les personnes. Un IDP robuste sans plan de rotation finit sur l'étagère. Associez chaque nouveau service self-service à un module de compétences et un check-in sur la sécurité psychologique.
4. Faire un audit de maturité. Vous ignorez par où ou par qui commencer? Contactez-nous. Mais pour arriver quelque part, il faut savoir d'où vous partez.

---

L'IA: sa place (et ses limites)

Les agents façon Copilot peuvent proposer des configs sécurisées et générer des tests automatiquement. Mais ils ne peuvent pas:

• Négocier les critères d'acceptation avec les parties prenantes.
• Décider de l'appétence au risque de votre organisation.
• Mener une rétrospective sur la fuite d'un bug critique.

L'automatisation est le valet de parking, pas le chauffeur.

Un mot sur la durabilité

Le rapport suggère des économies en éliminant les tâches manuelles. Économiser de l'argent, c'est bien ; économiser l'énergie, la charge cognitive et le moral, c'est mieux. L'organisation logicielle la plus durable est celle qui :

• Déploie avec peu de carbone et peu de cortisol.
• Apprend plus vite qu'elle ne brûle ses talents.
• Automatise l'ennuyeux et laisse de l'espace à l'humain pour la maîtrise.

Dernières réflexions

Les données Harness ne sont pas un "doom-scroll": c'est un miroir. Oui, la plupart des équipes végètent dans les limbes de maturité intermédiaire. Mais les miroirs ont du pouvoir: dès qu'on voit l'écart, on peut le combler.

Optimisons-nous les pipelines en ignorant les gens?

Poursuivons-nous la vélocité au détriment de la résilience?

Achetons-nous des outils pour masquer les symptômes ou investissons-nous dans la culture pour guérir les causes?

Je sais quelle réponse me garde dans le sport sur le long terme. Et vous? Poursuivons la discussion. Partagez le plus grand défi ou succès DevOps de votre équipe dans les commentaires, et bâtissons ensemble une culture d'ingénierie plus sécuritaire, durable et humaine.

Références:

#	Source	Éditeur
1	The State of Software Engineering Excellence 2025	Harness
2	New report reveals alarming state of software engineering excellence …	PR Newswire
3	Accelerate State of DevOps Report 2023	Google Cloud / DORA
4	Accelerate State of DevOps Report 2024	Google Cloud / DORA
5	Organisations are failing on DevOps experience and maturity	Digit.fyi
6	Measuring GitHub Copilot's Impact on Productivity	Communications of the ACM
7	Predicting Attrition among Software Professionals: Antecedents and …	ACM Digital Library

Is Engineering Excellence an Endangered Species?

A SecDevOps Reflection on the 2025 "State of Software Engineering Excellence" Report

---

Why this report matters to me

If you've followed my writing, you know I treat DevOps (and its grown-up sibling, SecDevOps) as a team sport that balances speed with safety, people with process, and sustainability with shareholder value. When Harness published its State of Software Engineering Excellence 2025 study last week, I grabbed a coffee and devoured all 30-plus pages. 

The headline is blunt: most organisations are still missing the mark on developer experience and DevOps maturity, and they're paying for it in lost productivity, spiralling risk, and frustrated talent. (harness.io)

---

Snapshot of the findings

Trouble spot	Survey data
Slow feedback loops	67 % of teams can't spin up a full build/test environment in 15 minutes
Manual toil	64 % still deploy infra code by hand; 50 % ship apps manually
Code-review drag	61 % wait > 1 day for a review
Quality gates missing	55 % of CI/CD pipelines lack any gating
Incident readiness gaps	52 % lack key tools for incident response
Security blind spots	38 % don't scan builds; 1 in 10 let critical bugs hit prod; median fix time ≥ 7 days for high-severity vulnerabilities.

Add to that:

• Only 29 % have an up-to-date software catalogue.
• Just 19 % provide structured up-skilling for devs.
• A quarter of teams admit > 70 % of user stories lack clear acceptance criteria.

Put bluntly again, the DevOps engine is knocking, the check-security light is flashing, and we're still driving 120 km/h on the 132.

---

Why does this gap persist?

In my consulting rounds I see three recurring anti-patterns:

1. Role-centric "DevOps" – Hiring a "pipeline wizard" and hoping magic trickles outward.
2. Tool-first obsession – Buying best-of-breed widgets without addressing processes or team dynamics.
3. Short-term velocity worship – Shipping features faster today while stacking tomorrow's technical debt (and stress injuries).

The Harness data validates all three: lots of shiny tools, but manual gates; pockets of excellence, but no cross-functional ownership; heroic engineers, but brittle systems.

---

Pros of the current trajectory (yes, there are some)

What's working	Why it still deserves credit
Awareness is up	650 leaders cared enough to benchmark themselves, that's cultural progress.
Platform thinking is emerging	The study champions unified software delivery platforms — exactly what modern SecDevOps preaches.
Security training exists	56 %* are at least training devs annually. Not perfect, but a foundation. (harness.io)
Metrics beat anecdotes	Using a maturity assessment moves the conversation from "feelings" to evidence.

*(Glass-half-full side note: it also means 44 % train less than annually or never.)

---

Cons (the real cost centre)

• Productivity hemorrhage – Every 30-minute context switch waiting for a code review is compound interest on waste.
• Security debt – A week to patch high-sev vulns is an eternity to an attacker; supply-chain exploits don't wait for sprint planning.
• People burnout – Manual deployments and after-hours incidents create the very exhaustion AI tooling claims to cure.
• Innovation drag – Talent stuck chasing broken pipelines isn't inventing the next feature set.

Multiply those by global salary averages and you understand the "millions" Harness flags. (harness.io)

---

A SecDevOps lens on the recommendations

Harness (unsurprisingly) prescribes a platform-centric approach. I agree, with caveats.

Harness prescription	My SecDevOps-flavoured refinement
Automate pipelines end-to-end	Yes, but policy-as-code must gate every stage: SAST, SBOM, IaC drift, secrets scanning, Snyk, SonarQube.
Adopt internal developer portals (IDPs)	Absolutely, but ensure least-privilege defaults and guard-railed self-service to avoid "shadow IT/infra."
Upskill continuously	Non-negotiable. Pair mandatory secure-coding sessions with rotation in incident response to build real empathy.
Measure maturity across five dimensions	Do it, with DORA metrics to keep eyes on throughput and reliability and ideally a SecDevOps lens. (en.wikipedia.org)

---

Culture change beats platform change

You can't secure what you don't understand; you can't automate what you haven't agreed to standardise. That calls for:

• Blameless, brutally honest retrospectives – surface the frictions behind those < 15-minute build failures.
• Shared SLOs – dev, ops, and security owning the same uptime, MTTR, and change-failure goals.
• Sustainability KPIs – track on-call load, after-hours pages, and training hours as first-class metrics, not "nice to haves." (See the emerging Sustainable DevOps research. (arxiv.org) and our article  Sustainability Is the New Performance )

---

People friendliness: the missing variable

The report focuses on dollars and defects. Let's add a human dimension:

• Manual toil = burnout. 
• Waiting on reviews = disengagement. 
• Slow incident resolution = paging the same hero at 3 a.m.

Addressing these isn't just a retention strategy; it's risk management. Tired minds mis-configure prod.

---

My four-point action plan

1. Map the waste Time-in-queue, not lines-of-code, is my leading indicator. If your PRs sit more than 12 hours, fix the feedback loop before buying another scanner.

2. Shift security conversations left Tools catch patterns; humans catch plausibility. Schedule brown-bag threat-model sessions so devs smell danger before a pull request exists.

3. Invest in platform and people equally A robust IDP without a rotation plan is shelf-ware. Pair every new self-service feature with a skills module and a psychological-safety check-in.

4. Have a Maturity Assessment. You don't know how or by whom, please contact us. But you need to know where you are of you intend of getting somewhere.

---

Where AI fits (and where it doesn't)

Copilot-style agents can suggest secure configs and auto-generate tests. But they can't:

• Negotiate acceptance criteria with stakeholders.
• Decide your organisation's risk appetite.
• Hold a retrospective on why a critical bug slipped.

Automation is the valet, not the driver.

A note on sustainability

The study hints at cost savings from eliminating manual tasks. Saving money is great; saving energy, cognitive load, and morale is better. The most sustainable software organisation is one that:

• Deploys with low carbon and low cortisol.
• Learns faster than it burns talent.
• Automates the boring and leaves space for mastery.

Closing thoughts

Harness's data isn't a doom scroll; it's a mirror. Yes, most teams remain stuck in mid-maturity limbo. But mirrors are powerful: once you see the gap, you can close it.

So ask yourself:

Are we optimising pipelines while ignoring people? Are we chasing velocity and missing resilience? Are we buying tools to hide symptoms or investing in culture to cure causes?

I know which answer keeps me in the game for the long haul. What about you? Let's continue this conversation. Share your team's biggest DevOps maturity hurdle or success story in the comments, and let's build a more secure, sustainable, and human-friendly engineering culture together.

References:

#	Source	Publisher
1	The State of Software Engineering Excellence 2025	Harness
2	New report reveals alarming state of software engineering excellence …	PR Newswire
3	Accelerate State of DevOps Report 2023	Google Cloud / DORA
4	Accelerate State of DevOps Report 2024	Google Cloud / DORA
5	Organisations are failing on DevOps experience and maturity	Digit.fyi
6	Measuring GitHub Copilot’s Impact on Productivity	Communications of the ACM
7	Predicting Attrition among Software Professionals: Antecedents and …	ACM Digital Library