Ce que nos clients font réellement avec Argy, et pourquoi nous changeons de catégorie

Le 28 juin dernier paraissait notre précédente publication. Depuis cette date, nous avons volontairement suspendu les annonces marketing pour nous consacrer exclusivement au terrain, aux côtés des équipes techniques qui exploitent notre technologie au quotidien. Nous reprenons désormais la parole avec une cadence soutenable de deux articles par mois, ancrée dans les faits et les retours d'expérience vérifiables.

Cette période d'observation a apporté une clarification majeure sur notre produit, nos clients et la catégorie dans laquelle nous nous inscrivons.

Le point de départ : la continuité avec Le Développeur Augmenté

Dans notre article du 11 mars intitulé Le Développeur Augmenté : piloter la production logicielle au lieu de la subir, nous posions une hypothèse fondamentale : le goulot d'étranglement de l'ingénierie d'entreprise n'est pas un manque de talent, mais une saturation sous le poids des tâches répétitives et de la maintenance opérationnelle. Nous affirmions que les ingénieurs doivent conserver la supervision stratégique tandis qu'une chaîne outillée prend en charge l'exécution sous des règles strictes.

Les mois passés sur les parcs applicatifs de nos clients ont validé cette thèse, mais avec un enseignement inattendu sur la nature exacte du travail effectué.

L'observation de terrain : la réalité du parc applicatif existant

Sur le marché des outils de génération et d'assistance de code, la majorité des démonstrations reposent sur un scénario idéal : une application neuve, initialisée sur un dépôt vide, sans historique ni contraintes d'exploitation.

Ce n'est absolument pas ce que rencontrent nos clients.

Dans les organisations qui utilisent Argy, l'usage dominant ne porte pas sur la création d'applications neuves. Il porte sur l'entretien, la modernisation et la remédiation du parc applicatif déjà en production :

• La mise à jour de dépendances majeures et de bibliothèques vieillissantes.
• La correction de failles de sécurité et l'application des recommandations d'audit.
• L'adaptation des schémas de données et la fiabilisation des migrations.
• L'ajout de cas de tests de régression sur des modules critiques non documentés.
• La standardisation des pipelines d'intégration sur des bases hétérogènes.

Ce travail répétitif et contraint constitue une part majeure des efforts observés sur le terrain. Lorsque les organisations recourent à des prestations d'ingénierie externe ou à des contrats de tierce maintenance applicative (TMA) facturés au temps passé, ces tâches pèsent lourdement sur la capacité opérationnelle des équipes.

Le changement de catégorie : vers l'usine logicielle gouvernée

Ce constat nous a conduits à faire évoluer notre positionnement. Argy ne se définit plus comme un simple portail développeur ou une surcouche de Platform Engineering. Argy opère comme une usine logicielle gouvernée pour vos applications en production.

La différence n'est pas sémantique, elle est budgétaire et opérationnelle :

1. Une comparaison possible avec la prestation au temps passé : Lorsqu'une organisation achète des prestations journalières, la facture reflète une présence sans lien direct avec le volume unitaire de changements vérifiés. L'usine logicielle permet à l'inverse de suivre des lots de travaux qualifiés et documentés.
2. Une capacité d'exécution sous vos règles : Vos équipes ne subissent plus la dérive technique des prestataires tournants. Vos règles d'architecture, vos standards de test et vos exigences de conformité sont appliqués de façon systématique à chaque modification.

Raisonner à l'unité d'œuvre : une méthode de pilotage économique

Pour remplacer la facturation au temps passé, il est indispensable d'introduire une mesure économique rigoureuse. C'est l'objet de notre pilotage à l'unité d'œuvre (UO).

Une unité d'œuvre représente un incrément de livraison vérifié : une correction de bug qualifiée par un test de régression, une montée de version de dépendance validée sans rupture, ou une remédiation de configuration conforme aux politiques de sécurité.

Sur notre base d'observation arrêtée au 26 septembre 2026, portant sur 3 tenants en production sur une période de 3 mois, une unité d'œuvre livrée par l'usine a coûté entre 34 € et 42 € selon le mois (coût réel des crédits consommés rapporté aux UO livrées, pour un volume de 238 à 291 UO livrées pour 10 000 € de budget Argy observé ; mention indicative et non contractuelle, hors valorisation du risque évité).

Ce constat fournit une base objective pour dialoguer avec les directions de production et les achats : comparer ce que coûte un changement livré et testé par rapport à une facture de prestation journalière.

La distinction essentielle : ce qui est configuré et ce qui est mesuré

Une promesse d'automatisation ne vaut rien sans clarté méthodologique. Dans l'usine logicielle Argy, nous séparons strictement deux notions :

• Ce qui est configuré : Ce sont les garde-fous que vous définissez en amont. Les branches protégées, les outils d'analyse statique requis, les politiques d'accès aux données, les seuils de couverture et les règles de validation humaine.
• Ce qui est mesuré : Ce sont les données issues des exécutions réelles. Le nombre exact de tests exécutés, la conformité du diff aux standards déclarés, les journaux d'audit horodatés et le coût réel des crédits mobilisés.

On ne pilote pas une production logicielle sur des déclarations d'intention, mais sur des mesures vérifiables.

La gouvernance et la preuve : personne ne signe sa propre homologation

L'accélération de la production logicielle ne doit jamais se faire au détriment de la sécurité ou de la conformité réglementaire. Chez Argy, chaque changement livré est indissociable de sa liasse de preuve.

Cette liasse rassemble :

• La preuve du test rouge initial démontrant le problème ou le besoin.
• Le compte-rendu d'exécution des tests verts après modification.
• Le rapport d'analyse de conformité et de sécurité.
• La traçabilité complète des interventions et des validations.

Un principe cardinal guide notre architecture : aucun composant d'exécution ne signe sa propre homologation. Chaque lot produit fait l'objet d'une revue indépendante avant toute fusion sur vos branches principales.

Des paliers d'autonomie contractualisés

L'autonomie n'est pas un interrupteur binaire que l'on bascule à l'aveugle. Elle s'organise en paliers progressifs et contractualisés avec la direction technique :

• Le mode supervisé : L'ingénieur examine et valide chaque proposition de modification dans son terminal avant application.
• Le mode autonome encadré : Pour des catégories de tâches strictement délimitées (comme les montées de versions mineures de dépendances ou l'application de correctifs de style), l'usine exécute les travaux et prépare les branches avec leur liasse de preuve complète, soumises à approbation finale.

Le périmètre d'action est toujours restreint aux dépôts et environnements explicitement autorisés. La validation humaine reste le verrou ultime des décisions sensibles.

L'évolution des compétences : le rôle de Software Factory Engineer

L'automatisation ne supprime pas les développeurs ; elle élève leur niveau d'impact. C'est l'émergence du rôle de Software Factory Engineer (SFE).

Le Software Factory Engineer n'écrit plus manuellement du code boilerplate à la chaîne. Ses responsabilités s'articulent autour de missions à forte valeur ajoutée :

• Concevoir et faire évoluer les modules d'ingénierie et les standards de l'organisation.
• Définir les politiques de sécurité et les critères d'acceptation de l'usine.
• Superviser les lots complexes et arbitrer les choix d'architecture.
• Auditer les liasses de preuve et garantir l'alignement avec les exigences métier.

Ce qui reste du Platform Engineering

Ce changement de catégorie signifie-t-il l'abandon du Platform Engineering ? Absolument pas.

Le Platform Engineering demeure le socle technique indispensable : c'est lui qui fournit les fondations d'infrastructure, les conteneurs d'exécution, la connectivité sécurisée et la gestion des secrets. Mais pour les directions générales et les DSI, le Platform Engineering seul représentait souvent un centre de coûts difficile à valoriser.

En devenant l'infrastructure sous-jacente d'une usine logicielle capable de résorber la dette applicative et de livrer des changements mesurés, le Platform Engineering trouve sa véritable rentabilité.

Reprendre le contrôle de votre patrimoine logiciel

Le logiciel d'entreprise n'est pas destiné à être réécrit tous les trois ans au gré des effets de mode. Il est le cœur opérationnel de votre activité et mérite une maintenance prévisible, rigoureuse et économiquement mesurable.

Nous vous donnons rendez-vous deux fois par mois dans ces colonnes pour partager nos analyses concrètes, nos architectures de contrôle et nos retours d'expérience du terrain.

Pour explorer comment structurer vos premiers lots d'unités d'œuvre sur vos applications en production, découvrez notre grille tarifaire ou contactez nos équipes pour organiser un cadrage technique.