Agence Agerix

21/07/2026

Le risque a changé de camp.

Pendant des années, sécuriser une application, c'était sécuriser son périmètre réseau. Aujourd'hui qu'une part croissante du code est générée par une IA, le risque s'est déplacé vers l'intérieur : le code lui-même, ses dépendances, sa chaîne de construction.

La r***e de code n'est plus une option de confort. Elle redevient un maillon de sécurité. Mais réviser du code produit par une machine demande une autre grille : on ne cherche plus un raisonnement défaillant, on vérifie que les garanties attendues sont réellement présentes, pas seulement leur apparence.

Pour que cette r***e tienne à l'échelle, deux conditions. Qu'elle soit soutenable : ciblée par le risque et épaulée par l'outillage, plutôt qu'exhaustive et vouée à l'échec. Qu'elle soit vérifiable : adossée à des critères testables et à des indicateurs qu'une direction peut suivre, plutôt qu'à un « on a relu » qui n'engage rien.

Notre analyse complète, en commentaire.

13/07/2026

« Combien nous coûte l'IA mal utilisée ? »

C'est la question qu'un dirigeant m'a posée après avoir lu notre article sur le workslop. Je n'avais pas de chiffre à lui donner sur son périmètre, seulement la moyenne d'une étude américaine. Alors on a construit l'outil qui manquait.

Vous entrez votre effectif, vos salaires, votre temps de travail. Vous ajustez la part de collaborateurs touchés et la fréquence. Le coût annuel, les heures perdues et l'équivalent temps plein mobilisé pour rien s'affichent en direct.

Deux partis pris, parce que la méthode compte autant que le résultat :
Les chiffres de l'étude (part de personnes touchées, temps par incident) sont marqués comme tels. Tout le reste, vous le contrôlez. L'outil n'invente aucune donnée à votre place, il pose les vôtres.

C'est gratuit, sans inscription. Testez sur votre organisation, le chiffre surprend souvent.

29/06/2026

Votre application sur mesure fonctionne très bien.

Mais si la personne qui l'a développée disparaît demain, qui la fait évoluer ? Qui la répare ?

C'est le risque le plus sous-estimé du développement sur mesure. Pas la qualité du code, la dépendance à une seule personne.

Une application devenue « orpheline » est une fragilité silencieuse. Elle tourne, parfois pendant des années. Jusqu'au jour où il faut la modifier, et où il n'y a plus personne pour le faire.

Nous rencontrons ce cas régulièrement. Une école de musique nous a confié récemment exactement cette situation : un outil utile, mais sans personne pour le suivre.

La solution n'est pas de tout jeter dans la panique. C'est de moderniser vers des standards solides, que n'importe quelle équipe compétente peut reprendre. La pérennité ne devrait jamais reposer sur une seule tête.

Si votre outil métier dépend aujourd'hui d'une seule personne, ce n'est pas un détail technique. C'est un risque de continuité.

22/06/2026

La meilleure décision technique de ce projet ? Ne rien migrer.

Refondre l'application d'une organisation soulève presque toujours la même question : « et toutes nos données existantes ? »

Pour cette école de musique, nous avions toutes les cartes en main pour reprendre l'historique. Nous avions nous-mêmes conçu le modèle de données de l'ancienne version. Techniquement, aucune difficulté.

Nous avons quand même choisi de ne pas le faire.

Les inscriptions de l'école se concentrent en juin et en septembre. Faire cohabiter deux systèmes, ou migrer en pleine année, c'était risquer qu'un élève souscrive d'un côté pendant que l'autre se mettait en place. Son directeur voulait l'éviter, et il avait raison.

Un démarrage propre, calé sur l'ouverture de la nouvelle saison, supprimait toute période où il aurait fallu maintenir deux outils en parallèle.

Savoir faire une chose ne suffit pas. Savoir quand ne pas la faire, et l'expliquer clairement au client, fait aussi partie du métier.

C'est souvent là que se joue la différence entre livrer un projet et réussir un projet.

19/06/2026

« Faut-il arrêter d'utiliser l'IA pour développer ? »
Non. Et ce n'est même pas la bonne question.
Un agent de codage est excellent sur les tâches locales et bien cadrées, qui représentent une grande part du travail. Le retirer serait absurde.
Ce qu'il ne fait pas, structurellement, c'est le travail systémique : tenir l'architecture et la vue d'ensemble, poser une bonne fois les politiques transverses (sécurité, gestion des erreurs, cohérence des données), assurer le durcissement de production. Ce travail-là ne tient pas dans une fenêtre de contexte, parce qu'il vit à l'échelle du système entier et du temps long.
La vraie question n'est donc pas « l'IA ou les ingénieurs », mais la division du travail : l'agent exécute vite, un humain tient le cadre. Même outil, résultats opposés, selon que quelqu'un tient ce cadre ou non.
Les projets qui s'enlisent ont presque tous le même profil : la vélocité interne existe, mais le contrepoids systémique manque. Pas de r***e d'architecture, pas d'audit de la dette, pas de discipline de production.

17/06/2026

Une école de musique parisienne vient de libérer l'équivalent d'un temps plein. Sans embaucher personne.

Voici son histoire.

L'Académie du 13 s'appuyait sur une application de gestion développée sur mesure, des années plus tôt. Le problème : le prestataire d'origine ne pouvait plus la suivre. L'outil était devenu orphelin. Il fonctionnait, mais plus personne ne pouvait le faire évoluer ni le réparer.

Nous l'avons reprise en 2022, stabilisée, maintenue quatre ans. Puis est venu le moment de moderniser pour de bon.

La vraie limite de l'ancien outil n'était pas son âge, c'était sa conception : un logiciel réservé à l'administration. Les élèves ne s'inscrivaient pas eux-mêmes, l'équipe saisissait tout à la main. Les paiements étaient notés, jamais déclenchés. Tout reposait sur le temps des salariés.

La nouvelle plateforme renverse la logique. Élèves, parents et professeurs gèrent désormais leur propre compte, s'inscrivent et règlent en ligne. Les relances, les justificatifs, les notifications : l'application s'en charge.

Le résultat, selon son directeur : près de 1 000 heures de saisie et de support évitées chaque année. L'équivalent d'un poste à temps plein, réinvesti dans ce qui fait vivre une école de musique, la pédagogie.

Le travail répétitif n'a pas été accéléré. Il a disparu.

C'est ça, pour moi, une modernisation réussie.

16/06/2026

Le code généré par IA se lit bien, tourne, passe la démo. C'est précisément ce qui pose problème.
D'habitude, la dette technique se contracte en connaissance de cause : on sait qu'on coupe un angle, et on le note. Quand un humain écrit chaque ligne, il sent le couplage, le test absent, le raccourci.
L'agent supprime cette friction. C'est tout son intérêt. Mais c'est aussi ce qui supprime le signal : la dette est contractée sans que personne ait décidé de la contracter. Couplage implicite, cas d'erreur jamais écrits, modèle de données taillé pour la démo. Rien de visible tant que le prototype tourne.
Et voici l'asymétrie qui coûte cher : réparer un système dont la dette a fait des intérêts coûte bien plus que de l'avoir bien construit d'emblée. La vitesse qui semblait gratuite au stade du prototype était un emprunt. L'échéance tombe en production, sous charge, avec de vraies données. Au pire moment pour découvrir la facture.

11/06/2026

Votre prototype IA fonctionne. Et trois mois plus t**d, il n'est toujours pas en production.
Ce n'est presque jamais un échec de l'outil ou de l'équipe. C'est l'arête visible d'une distinction que l'IA n'a pas inventée, mais qu'elle a rendue beaucoup plus nette : écrire du code et concevoir un système ne sont pas le même travail.
Le premier est devenu rapide et bon marché. Un agent de codage produit une fonction, une interface, un script plus vite qu'un humain, et souvent aussi bien. C'est une part énorme du quotidien d'un développeur.
Le second reste un métier. Un système, c'est ce qu'aucune tâche isolée n'exprime : la cohérence d'ensemble, les invariants, la sécurité, la montée en charge. Tout ce qui n'est pas « la fonctionnalité », et qui ne se vérifie pas en lançant une fois la démo.
La démonstration exerce le ponctuel. La production exerce le systémique. C'est tout l'écart entre « ça marche » et « ça tient ».
La valeur n'a pas disparu quand le code est devenu facile à produire. Elle s'est déplacée : de produire le code à tenir le système debout.

02/06/2026

Trois articles pour lire Claude Code 4.7 autrement.
La presse tech a couvert les annonces en boucle. Ce qui manquait à cette couverture, c'était la lecture que peut en faire un bureau d'étude qui passe ses journées sur des applications métier de PME et d'ETI. Trois questions, trois articles.
Le premier — l'advisor pattern — a regardé l'architecture interne de Claude et y a reconnu une logique de subsidiarité technique. Le sujet n'est pas l'API ; c'est ce que ce pattern dit, en miroir, de nos propres applications.
Le deuxième — les routines — a montré comment l'IA agentic quitte le poste du développeur pour devenir une fonction d'infrastructure. Ce basculement déplace la question du terrain technique vers celui de la gouvernance : permissions, périmètre de décision, traçabilité, responsabilité. Quatre questions qui ne sont plus celles d'un développeur, mais celles d'un DSI.
Le troisième — le cycle de vie — a posé la question la plus opérationnelle : sur quelles étapes d'une application métier l'IA agentic crée-t-elle vraiment de la valeur, et sur lesquelles en détruit-elle ? La réponse tient dans une grille à deux axes, valeur effective et réversibilité des erreurs, et trois postures : automatiser, assister, protéger.
Trois plans — architecture, gouvernance, opérationnel — qui ne sont pas trois perspectives concurrentes, mais trois profondeurs de la même question. L'IA agentic devient une ressource programmable. Et une ressource programmable appelle des choix délibérés, à chacun de ces trois niveaux.
Les trois articles sont en commentaire.

30/03/2026

Question sincère pour les CTOs et Engineering Managers qui gèrent un SI en croissance :
Pouvez-vous expliquer en 3 phrases comment vos systèmes communiquent entre eux — et pourquoi ils ont été conçus ainsi ?
Je pose cette question régulièrement en début de mission. Et la réponse la plus fréquente, c'est un silence gêné suivi de "il faudrait demander à [personne qui a quitté l'entreprise il y a 2 ans]".
Ce n'est pas un problème de compétence. C'est un problème d'explicitation.
Dans une scale-up qui passe de 30 à 100 personnes, chaque nouveau collaborateur, chaque nouveau module, chaque intégration ajoute une couche d'implicite. Des choix d'architecture que plus personne ne questionne. Des flux entre systèmes qui contournent un bug jamais corrigé. Des processus métier que "tout le monde connaît" — mais que personne ne décrit exactement de la même façon.
Et tant que tout fonctionne, personne ne s'en inquiète. C'est le jour où un composant tombe, où un prestataire change, ou où un nouveau besoin révèle les limites d'une architecture jamais documentée que le coût de cet implicite explose.
Alors je suis curieux :
À quel moment avez-vous réalisé que votre SI contenait plus d'implicite que vous ne le pensiez ? Qu'est-ce qui a déclenché cette prise de conscience ?
Cette question est au cœur d'un article que j'ai écrit sur l'explicitation en ingénierie logicielle — la discipline qui consiste à rendre visible ce qui reste dans les têtes, à chaque échelle du SI.
J'y détaille un framework à 4 niveaux (code → composant → projet → SI global) avec des méthodologies concrètes pour chaque échelle : du nommage de variables jusqu'à la cartographie applicative, en passant par le kick-off structuré et la matrice RACI.
👉 https://www.agerix.fr/blog/du-canard-en-plastique-a-laudit-si-pourquoi-lexplicitation-est-la-competence-la-plus-sous-estimee-en-ingenierie-logicielle?utm_source=linkedin&utm_medium=social&utm_campaign=post-question-engagement&utm_content=profil-personnel
Si votre réponse à ma question vous a mis un peu mal à l'aise, l'article devrait vous donner des pistes concrètes pour y remédier.

Du rubber duck debugging à l'analyse de projet : découvrez pourquoi l'explicitation structurée est le mécanisme qui distingue les projets IT maîtrisés de ceux qui déraillent, à chaque échelle de votre SI.