Martin Catty - Notes

Je n’ai plus envie d’utiliser d’apps.

2026-10-13T00:00:00Z

Je me souviens d’il y a encore quelques années, de l’adrénaline que je ressentais en testant une nouvelle application. Et de celle décuplée en la concevant.

Ce sentiment de pouvoir faire plus, plus vite. L’excitation du « ça marche ». Aujourd’hui je cherche tous les moyens de l’éviter.

Devoir aller sur telle URL, s’y connecter, rentrer ton 2FA, valider les N notifications, bandeaux de cookies, saisir des informations dans des formulaires interminables, attendre que le serveur veuille bien répondre sans nous livrer une erreur obscure avec un code incompréhensible.

Cela fait 20 ans que je fais partie de cette industrie. Des apps j’en ai conçu des centaines.

Notre industrie a empilé les couches pendant des dizaines d’années, à tel point qu’il fallait (faut) se rendre expert d’une dizaine de domaines différents pour concevoir une app (architecture, design, dev (back / front), sécurité, infrastructure, légal, accessibilité…).

On a conçu des standards qui visaient à maintenir des apps pendant des décennies. Des tonnes de niveaux d’abstraction car « si ça change on sera prêt ». Spoiler ça n’a jamais changé.

Est-ce qu’on ne devrait pas accepter une fois pour toutes qu’on crée du jetable ?

Est-ce que l’ère de l’IA ne nous offre pas l’opportunité d’avoir des apps à la demande (et c’est OKKK) ?

À force de sur-déléguer à l'IA, on tue son propre poste

2026-09-13T00:00:00Z

J'aime beaucoup cet article AI Is Breaking This Thing We Call Trust.

En bref, quand quelqu'un t'envoie un PR ou une doc, tu ne pars plus du principe qu'il a compris ce qu'il produit. Tu te demandes d'abord s'il assume vraiment ce qu'il envoie.

Si on pousse un cran plus loin, le vrai risque, pour un développeur, ce n'est pas que l'IA écrive du code.

C'est de se vider de ce qui justifie encore sa place.

Tu ne portes pas la trajectoire produit. C'est le Product Owner. Tu n'écris plus vraiment le code. C'est l'IA. Tu ne le reviewes pas vraiment non plus. C'est le lead.

À ce stade, ta valeur ajoutée est moindre que celle d'un agent.

La sur-délégation a un côté confortable. Tu livres plus vite. Tu as l'air productif. Le ticket passe.

Mais tu te retires progressivement du jeu : moins de compréhension, moins de jugement, moins de responsabilité. Et un jour, la question n'est plus "est-ce que l'IA peut faire mon travail ?" Elle devient "qu'est-ce que j'apporte encore que l'IA ne fait pas déjà ?"

La confiance dont parle l'article, c'est le symptôme. Le fond, c'est le dev qui scie la branche sur laquelle il est assis.

Si tu veux rester pertinent, il faut garder la main sur au moins une chose difficile : le produit, le code, l'architecture, la revue. Idéalement plusieurs d'entre elles, à des doses variables. Mais pas zéro.

Sinon tu n'es plus un développeur. Tu es un intermédiaire entre un ticket et un LLM.

Spoiler : le métier de prompt engineer dont tout le monde parlait il y a 3 ans et demi n'existera finalement pas.

La qualité de code, c'est juste la vélocité dans la durée

2026-09-12T00:00:00Z

Il faut qu'on parle qualité de code.

La qualité de code, pour moi, ce n'est qu'une chose : la capacité à continuer à construire et enrichir une app de manière constante.

Quand on dit ça, à mon sens, ça englobe tout.

Si ton code n'est pas lisible, mal architecturé, avec des méthodes de 200 lignes, revenir dessus devient pénible. Onboarder aussi. Et in fine, tu réduis ta vélocité.

À l'heure de l'IA ? Pas besoin d'un modèle frontière pour avoir un code d'aussi bonne qualité que 90 % des devs. Et dans 100 % des cas, ce sera produit plus rapidement.

Depuis trois ans, je code de manière assistée en Ruby, Elixir et Go. Mention spéciale à Go, où l'IA est vraiment impressionnante. Sur la qualité du code produit, je n'ai pas grand-chose à redire.

Je n’ai vraiment que deux bémols.

Le premier : le côté "solution à tout prix". L'IA n'hésitera pas à faire des choses inmaintenables pour atteindre l'objectif. Ça semble presque dans son « ADN », je n’ai vu aucune rules qui permettait vraiment d’éviter ce comportement.

Le second : l'extension de périmètre. Elle cherche souvent à aller au-delà de ce qui est demandé, fonctionnellement. Parfois c’est positif car tu as vraiment oublié quelquechose, d’autre fois non. Le recours au mode plan systématique corrige une bonne partie de ce problème.

La production de code devient cheap, ce qui m’amène une question :

La qualité du code est-elle encore une bonne métrique ?

Le monde est devenu des tokens

2026-09-12T00:00:00Z

Token.

C’est peut-être le mot de la décennie.

Celui qui dit quelque chose de notre époque : la priorité donnée à la machine, parfois au-delà de l’humain.

C’est fou à quel point tout devient token.

Une société se lance, elle crée son token.

Des actifs physiques sont tokenisés sur une blockchain.

Vous parlez à votre LLM, il découpe votre phrase en tokens.

On a créé des indirections partout.

Un peu comme dans un jeu vidéo, quand vous convertissez votre argent en monnaie virtuelle : la distance rend la dépense moins douloureuse.

Le token ne sert pas seulement à simplifier le réel.

Il sert à le rendre manipulable par des machines.

Par des robots, des agents, des IA, des marchés automatisés.

À force de traduire le monde dans un langage optimisé pour les machines, on finit par demander aux humains de s’adapter à cette grammaire.

Ce n’est plus seulement la machine qui apprend à comprendre le réel.

C’est le réel qu’on découpe pour qu’il devienne exécutable par la machine.

Est-ce que ce n’est pas une forme de déshumanisation ?

L'IA nous pousse à prendre de mauvaises décisions

2026-09-12T00:00:00Z

L'IA nous pousse à prendre de mauvaises décisions.

Dans beaucoup d'équipes, le temps de décision suit le temps d'exécution. Un sujet à six mois passe par des comités, des revues de risques, des allers-retours.

Un sujet à deux semaines se tranche en dix minutes. Ce n'est pas automatique, mais c'est un réflexe très courant. On se dit qu'au pire, on pourra ajuster plus tard.

Comme l'IA compresse énormément le temps d'exécution, on compresse aussi la réflexion.

C'est le problème du buffet à volonté. Tu te mets à vouloir goûter un peu de tout, parce que ce serait quand même dommage de ne pas le faire, c'est là pour ça.

Laisser un agent ne rien faire ? Quelle hérésie !

Alors on fait en sorte que nos agents restent actifs, quitte à leur faire faire n’importe quoi. On se raconte que ce n'est pas grave, qu'on ajustera en route parce qu'on est agiles.

Mais être agile ne veut pas dire ne pas avoir de plan.

En plus de ça, avec des barrières techniques plus basses, le moat logiciel se réduit. Si tout le monde exécute vite, une mauvaise décision stratégique coûte plus cher qu'avant.

La vraie question n'est peut-être plus "peut-on livrer vite ?" Mais "comment protéger le temps de réflexion quand livrer devient presque instantané ?"

On a transformé du texte en usine à gaz.

2026-09-12T00:00:00Z

Tu te souviens du web où l’essentiel de la page était le texte que tu venais lire ?

Pas de cookies, de consentement, de pop up, pop in, pop whatever.

Pas 10 Mo de JS chargés à chaque page. Pas de SPA pour un site vitrine. Pas de node_modules de 5 Go sur ta machine pour un site de 5 pages.

En entreprise, c’est pareil. On se partage des fichiers Word sur SharePoint. Une fois sur deux, tu n’as pas accès.

L’autre fois, c’est « attends, ce n’est pas la dernière version ». Ou alors tu ne peux pas éditer. Ni commenter. Ou tu n’as tout simplement pas la licence Office.

Tout ça, c’est du texte. Juste du texte. Et ça devrait être géré comme tel : en séparant le fond de la forme.

À l’ère des LLM, c’est encore plus vrai. Les LLM mangent du texte. Si tu leur donnes des fichiers binaires, la première chose qu’ils feront sera de les transformer en texte.

Quand tu gères ta documentation comme du texte, le levier est énorme. Un LLM est meilleur que toi pour relier le contexte à grande échelle. Si une page A est liée à la B sur laquelle tu travailles, il peut mettre à jour la page A sans même que tu lui demandes.

L’outil sur lequel je travaille applique exactement cette logique. Il démultiplie les capacités des équipes techniques en prenant trois inputs : le code, l’état des services utilisés (GitLab, GitHub, Kubernetes…) et la documentation existante.

Tout ça n’est que du texte. Et quand c’est géré comme tel, le levier de productivité est phénoménal. Notamment parce que tu bénéficies de boucles de rétroaction.

L’état de tes services et de ton code alimente ta documentation. Et ta documentation aide à contextualiser tes agents qui modifient l’état de tes services (idéalement via ton code).

La vraie question n’est pas technologique.

Elle est culturelle : est-ce que ton organisation considère le texte comme un actif stratégique ?

Ou juste comme un livrable à produire ?

L’arrivée des agents IA dans nos métiers me fait penser… aux 5 phases du deuil.

2026-09-12T00:00:00Z

Déni : « Ça ne marchera pas chez nous. Trop spécifique. Trop risqué. Trop buzzword. »

Exemple : « On a essayé Copilot, c’était nul. »

Colère : « Ça va remplacer des jobs / baisser la qualité / c’est du shadow IT. »

Exemple : sécurité qui serre les boulons, devs frustrés, ops qui sentent venir la pression.

Marchandage : « Ok, mais seulement pour X, pas pour Y. » / « On fera un POC… sans prod, sans données réelles, sans accès. »

Exemple : on garde tous les process inchangés… et on “colle” juste un agent par-dessus. Ou on monte un chatbot “maison”, pendant que les utilisateurs continuent d’aller sur des plateformes tierces (Anthropic, OpenAI…).

Tristesse : « On réalise que le terrain bouge vraiment. »

Exemple : fatigue, impression d’être en retard, perte de repères (« mon expertise vaut quoi demain ? »).

Acceptation : « Bon. C’est là. Maintenant, comment on l’utilise intelligemment ? » Variante de l’acceptation, en mode mauvaise foi : « Je vous l’avais dit. »

Exemple : montée en compétence, standards, gouvernance, garde-fous (permissions minimales, audit, validation humaine).

Vous en êtes à quelle phase, honnêtement ?

Coder à la main, comme conduire à la main

2026-09-12T00:00:00Z

Tu codes encore à la main ? Tu conduis encore à la main ?

C'est assez fou ce genre de phrase. Je n'aurais jamais imaginé les prononcer il y a 15 ans.

Pourtant le levier des outils à notre disposition est tellement énorme que j'ai du mal à comprendre pourquoi la bascule n'est pas plus rapide. Peur de perdre le contrôle ?

Habitude ? Ou simplement le confort de faire comme avant tant que la pression business ne force pas à changer.

Et même : quel plaisir prennent encore les développeurs à taper des lignes de code ?

Notre plaisir c'est plutôt d'apprendre pour construire des choses qui répondent à des besoins, non ?

Pourtant je vois encore pas mal de développeurs revendiquer cette approche craft, ce côté fait à la main. Est-ce que ça a du sens pour quelque chose qui peut être copié à l'infini comme du code ?

Je peux le comprendre pour le tonnelier qui fabrique son fût en chêne. Vous entrez dans sa boutique, ça sent bon et vous avez face à vous un objet unique. Le code, lui, n'est pas unique. Ce qui l'est, ce sont les choix : quoi construire, dans quel ordre, avec quels compromis. L'architecture, le produit, la compréhension du besoin. Pas la syntaxe.

Automatiser l'écriture du code ne tue pas le métier. Ça déplace la valeur vers ce qui reste difficile à copier : la décision, la vision, le feedback avec le terrain. Le craft pourrait devenir ça. Ou pas.

L'ingénierie logicielle va de plus en plus récompenser ceux qui ont de la vision et savent déléguer l'exécution aux machines. L'IT était un des derniers bastions où l'on pouvait être un exécutant — bien payé, en télétravail, reconnu — sans porter la responsabilité du cap. C'est en train de se terminer.

La question qui me reste : dans cinq ans, est-ce qu'on regardera encore "écrire du code à la main" comme un signe de sérieux, ou comme un luxe que plus personne ne s'offre ?

J'ai bien rigolé en tombant sur l'observatoire Proton

2026-09-12T00:00:00Z

Au risque de me faire tacler, le plus surprenant dans cette étude (que tout le monde devrait lire), c’est que la Suisse se considère dans l’Europe.

https://proton.me/fr/business/europe-tech-watch

Merci à Bearstech pour le partage

Vous aussi vous aimez quand on parle votre langue ?

2026-09-12T00:00:00Z

C'est pareil dans la tech. Les ingénieurs aiment qu'on parle dans leur langue ou plutôt leur langage.

On sous-estime à quel point c'est fatiguant pour des équipes techniques, qui se passionnent pour mettre en place des systèmes robustes, performants, résilients, qu'on leur parle uniquement en temps et en argent.

Exemple de conversation, pas si fictive :

Tech : On a réussi à mettre en place X pour le client Y, ça va résoudre le problème Z
Manager : Est ce que ça a un impact sur le planning ? Est ce que ça nous permet de compresser le temps restant ? Tu as pu traiter N ? Est ce que tu as mis à jour le ticket ?

Ce genre d'échanges crée une lassitude avec des effets de bord invisibles. Les personnes se mettent à ne plus communiquer ou pire à ne plus rien essayer. Elles vont lentement glisser pour rester dans leur couloir en dépilant des tickets.

Le message perçu côté tech : « ça ne m'intéresse pas les petites tâches, moi je gère des enjeux plus grands »

Je ne dis pas que les équipes tech ne doivent pas être sensibilisées au business, bien au contraire. Par contre, à utiliser la main-d'œuvre comme des agents IA on perd des deux côtés.

On n'obtient ni l'efficacité d'un agent, ni la créativité et la profondeur de réflexion d'un humain.

Les équipes qui performent ont souvent des managers qui sont d'excellents proxy. Ils parlent technique aux ingénieurs et business aux dirigeants.

Il n'y a pas plus performant qu'un ingénieur qu'on stimule sur son terrain de jeu plutôt que de le faire crouler sous du reporting.

CKA dans la poche !

2026-09-12T00:00:00Z

https://www.credly.com/badges/a4c73499-219f-4de7-b295-5719fb18d080/public_url

Cette année j'ai décidé de prendre le temps de passer des certifications. Pas pour collectionner les badges, mais pour me challenger sur des sujets que je pensais maîtriser.

La Certified Kubernetes Administrator a l'avantage d'être une certification pratique. Exit le QCM, vous êtes dans votre terminal à résoudre des problèmes.

Je travaille avec Kubernetes depuis 2017. Pourtant, en préparant l'examen, j'ai découvert des zones que je n'avais finalement que peu explorées. Kubeadm, Kustomize, des sous commandes de kubectl.

L'examen en lui-même est strict. Surveillance webcam, pièce inspectée sous tous les angles, interdiction de mettre la main devant la bouche (oui c’est du vécu).

Pour éviter les problèmes de setup je l’ai passé directement sur mon Mac, dans la chambre de ma fille. Sans mon écran externe et mon Ergodox EZ j’étais un peu perdu 😅.

J’ai d’ailleurs eu des soucis de caractères spéciaux à plusieurs reprises. Impossible de faire des | ou autre {}, il a fallu ruser.

Malgré tout, est-ce que ça vaut le coup ? Oui, sans hésiter. Pas pour le badge, mais pour le chemin parcouru. Même avec de l'expérience, on a toujours des angles morts.

Est-ce que les problèmes à résoudre reflètent la réalité ? Pas vraiment. Personne ne s’amuse à taper et appliquer des manifests à la main depuis une node Kubernetes. Enfin j’espère.

Même votre collègue le plus espiègle ne va pas insérer des typos dans les manifests de static pod de votre cluster de production. Enfin j’espère bis.

Pour la suite, je vise la CKS. Les autres certifications CNCF sont clairement trop simples pour justifier leur coût. 250$ pour un sticker, c'est cher payé.

D’ailleurs Denis, qui les a toutes, a fait un résumé complet de son expérience que je vous invite à lire.

https://blog.zwindler.fr/2026/01/18/rex-kubestronaut/

Recruter des personnes avec de l'énergie positive

2026-09-12T00:00:00Z

Après des dizaines d'embauches, en analysant a posteriori quels profils avaient le plus apporté, j’ai identifié 2 critères qui ressortent au-dessus de tous les autres.

Note : J'ai vendu ma société il y a 3 ans et j'ai démissionné du repreneur il y a un an. Cela m'a permis de prendre du recul sur ce qui avait bien et moins bien fonctionné sur différents sujets que je partage avec vous.

Note 2 : Ce contenu n’engage que moi, aucune des sociétés auxquelles je contribue ou ai contribué.

Le premier critère est l'énergie. Le deuxième critère est l'attitude positive.

À ce stade vous vous dites sans doute deux choses.

1/ c’est très large comme critères et sans doute difficile à évaluer

Pourtant, je suis sûr que si vous fermez les yeux 10 secondes vous pouvez classer n’importe lequel de vos collègues dans une de ces 4 catégories : énergie + positif, énergie + négatif, pas d'énergie + positif, pas d'énergie + négatif.

2/ qui des compétences ?

Concernant le point des compétences, je n'ai jamais connu quelqu'un avec de l'énergie et positif qui échoue sur le plan des compétences. Quand vous avez ce type de profil dans votre équipe ils peuvent abattre des montagnes et votre rôle est de les garder dans cette zone.

Le ratio de contribution à l'entreprise des personnes à énergie positive est incroyablement plus élevé. J'ai vu des équipes de 3 personnes performer nettement plus que des équipes de 10+.

Au passage, l'utilisation de l'intelligence artificielle agit non pas comme un outil permettant de mettre tout le monde sur la même base en terme d'impact, mais plutôt comme un levier supplémentaire de performance accentuant l'écart.

Le profil énergie + positif est celui qui va être dans l'amélioration continue, proposer des nouvelles choses et accompagner les équipes. Il demande finalement peu de management, mais il a besoin d'espace et d’autonomie pour s'exprimer et qu'on reconnaisse son travail en le valorisant. Le pire à faire est de le sous alimenter.

Le profil énergie + négatif, c'est le sauveur. Il performe mais il devient vite toxique pour la société. Il joue plus pour son compte que pour le collectif, et il le sait. C’est un cas très complexe à gérer car si à court terme il apporte beaucoup, à long terme il vous pénalise.

Le pas d'énergie + positif, c'est l'animateur. Il est utile dans une certaine mesure à maintenir une bonne cohésion d'équipe et créer du lien. Il fait avancer modestement les projets, mais sans lui la machine peut se gripper.

Le pas d'énergie + négatif, c'est le saboteur. Il critique tout et tout le temps, et cache ses manques derrière les autres.

La plus grande difficulté dans mon expérience, c'est que les personnes ne changent jamais en mieux. Elles vont progressivement tendre vers moins. Gardez en tête que le voyage ne se fait que dans un sens.

Spoiler : Donner plus d'argent à quelqu'un ne le fera pas changer de catégorie, en tout cas pas durablement.

Trouver en amont les bonnes personnes est donc aussi important que de garder ceux qu'on a à leur plein potentiel.

Mais pour ça il n’existe pas de recette miracle, ou si vous l’avez 👇