CodingTech Hub

Le monde du code a une drôle d’histoire. Beaucoup pensent encore que la programmation est un domaine “récent” dominé par les hommes. Plot twist : les femmes étaient là dès le début… parfois même avant que les ordinateurs existent vraiment.

Au XIXᵉ siècle, une mathématicienne visionnaire imagine qu’une machine pourrait faire plus que des calculs. Cette femme s’appelait Ada Lovelace. En travaillant sur la machine analytique de Charles Babbage, elle décrit ce que beaucoup considèrent aujourd’hui comme le premier programme informatique de l’histoire. Oui, le premier “développeur” de l’histoire… était une femme.

Quelques décennies plus t**d, pendant la Seconde Guerre mondiale, plusieurs femmes deviennent les premières programmeuses de l’un des premiers ordinateurs électroniques : ENIAC. Parmi elles : Jean Jennings Bartik et Kathleen McNulty. Elles ont littéralement inventé les bases de la programmation moderne… sans documentation, sans tutoriel YouTube, et sans Stack Overflow.

Puis arrive une autre figure monumentale : Grace Hopper. Elle développe l’idée d’un langage de programmation compréhensible par les humains, ce qui mènera plus t**d à la création de COBOL, un langage encore utilisé dans de nombreuses banques aujourd’hui.

Ironie de l’histoire : dans les années 60–70, la programmation était souvent considérée comme un travail “de femme”. Ce n’est que plus t**d que l’image du programmeur change et que les femmes deviennent progressivement moins représentées dans le secteur.

La réalité est simple : le numérique n’a jamais été construit par un seul genre. Il est né de l’intelligence humaine… point.

Ce mois dédié aux femmes est donc l’occasion de se rappeler d’une chose essentielle : l’avenir du numérique a besoin de tous les talents. Et peut-être que la prochaine grande révolution technologique viendra d’une jeune fille qui découvre aujourd’hui sa première ligne de code.

Le futur du numérique n’attend personne. Mais il accueille tout le monde.

Coder, ce n’est pas juste faire marcher une machine.
C’est écrire quelque chose qu’un humain pourra comprendre… même dans 6 mois, même à 2h du matin, même quand ce n’est plus toi qui maintiens le projet.

Le *Clean Code*, ce n’est pas une lubie de développeur perfectionniste. C’est une discipline. Une forme de respect.

Le concept a été popularisé par Robert C. Martin (Uncle Bob) dans son ouvrage Clean Code. Son idée est simple et radicale :
un code doit être **lisible, clair et intentionnel**.

Un bon code ne fait pas seulement le travail.
Il raconte une histoire.

Un mauvais nom de variable, c’est du bruit.
Une fonction de 200 lignes, c’est un signal d’alarme.
Une duplication inutile, c’est une dette que ton “toi du futur” devra payer avec intérêts.

Clean Code, ça veut dire :
– Des noms explicites.
– Des fonctions courtes qui font une seule chose.
– Pas de magie obscure.
– Pas de complexité pour impressionner.

Parce que la vérité, c’est ça :
Un code “intelligent” mais illisible est un mauvais code.

Le développement logiciel est un travail d’équipe. Même en solo, tu collabores avec ton futur toi. Et crois-moi, il déteste décrypter du chaos.

Coder proprement, ce n’est pas ralentir.
C’est construire pour durer.

Les cathédrales ont traversé les siècles parce qu’elles étaient pensées, structurées, solides. Ton code mérite la même intention.

Écris pour être compris.
Pas pour impressionner.

💻 Le principe SOLID : un fondement essentiel du développement logiciel

Dans le développement, faire fonctionner un programme est une chose.
Le rendre maintenable, évolutif et structuré en est une autre.

Les principes SOLID, introduits par Robert C. Martin, constituent un cadre de référence incontournable pour concevoir des applications robustes et durables.

Ils reposent sur cinq règles fondamentales :

🔹 S – Single Responsibility
Une classe doit avoir une seule responsabilité, et donc une seule raison de changer.

🔹 O – Open/Closed
Le code doit être ouvert à l’extension, mais fermé à la modification.

🔹 L – Liskov Substitution
Une classe enfant doit pouvoir remplacer sa classe parent sans altérer le comportement attendu.

🔹 I – Interface Segregation
Mieux vaut plusieurs interfaces spécifiques qu’une interface trop générale.

🔹 D – Dependency Inversion
Les modules doivent dépendre d’abstractions, et non d’implémentations concrètes.

Adopter SOLID, c’est :

✔️ Réduire la dette technique
✔️ Améliorer la lisibilité du code
✔️ Faciliter les tests
✔️ Préparer l’évolution du projet

Un bon développeur écrit du code qui fonctionne.
Un développeur professionnel écrit du code qui dure.

́veloppementlogiciel

𝐀𝐧𝐭𝐡𝐫𝐨𝐩𝐢𝐜 𝐞𝐭 𝐎𝐩𝐞𝐧𝐀𝐈 𝐨𝐧𝐭 𝐬𝐨𝐫𝐭𝐢 𝐥𝐞𝐮𝐫𝐬 𝐦𝐨𝐝è𝐥𝐞𝐬 𝐝𝐞 𝐜𝐨𝐝𝐞 à 𝟏𝟓 𝐦𝐢𝐧𝐮𝐭𝐞𝐬 𝐝’𝐢𝐧𝐭𝐞𝐫𝐯𝐚𝐥𝐥𝐞. 𝐕𝐨𝐢𝐥à 𝐩𝐨𝐮𝐫𝐪𝐮𝐨𝐢 ç𝐚 𝐜𝐨𝐦𝐩𝐭𝐞 𝐯𝐫𝐚𝐢𝐦𝐞𝐧𝐭.

La semaine dernière était franchement un peu f***e.

Mercredi, Anthropic devait sortir Opus 4.6 à 10h. OpenAI, de son côté, sortait son nouveau modèle Codex… à 10h aussi. Exactement au même moment. Ce qui, quand on y pense, est déjà assez absurde — genre, ils se sont coordonnés ? Quelqu’un a fuité quelque chose ?

Bref. Anthropic a finalement décidé de… sortir 15 minutes plus tôt. 9h45. OpenAI est resté sur 10h. Résultat : deux annonces “le modèle de code le plus avancé jamais créé” à un quart d’heure d’intervalle.

J’étais en train de rafraîchir Hacker News et X en boucle pour suivre. C’était le chaos. Un chaos fun, mais du chaos quand même.

Cela dit, après avoir passé la semaine à utiliser les deux modèles, j’ai quelques réflexions qui vont au-delà de “wow, les benchmarks sont élevés”.

𝐂𝐞 𝐪𝐮’𝐎𝐩𝐮𝐬 𝟒.𝟔 𝐟𝐚𝐢𝐭 𝐯𝐫𝐚𝐢𝐦𝐞𝐧𝐭 𝐝𝐢𝐟𝐟é𝐫𝐞𝐦𝐦𝐞𝐧𝐭

La fonctionnalité phare, ce sont les “équipes d’agents” : en gros, tu peux lancer plusieurs instances de Claude qui travaillent en parallèle sur différentes parties d’un projet. Un pour le frontend, un pour l’API, un autre pour les migrations de base de données. Ils communiquent entre eux et se coordonnent.

Je l’ai testé sur une base de code de taille moyenne au boulot. Résultat mitigé, honnêtement.

Quand ça marche, c’est vraiment impressionnant. J’avais trois agents sur différentes parties d’un refactor, et ils ont fait en 20 minutes ce qui m’aurait pris quelques heures. Ils ont même détecté un conflit entre deux de leurs modifications et l’ont résolu sans que j’intervienne.

Quand ça ne marche pas, c’est agaçant. Deux fois, des agents se sont marché dessus d’une manière qui m’a obligé à démêler ça à la main. Pas catastrophique, mais clairement pas l’expérience “je lance et j’oublie” qu’Anthropic vend.

En revanche, la fenêtre de contexte d’un million de tokens est bien réelle. J’ai balancé toute notre base de code — environ 50 000 lignes — et je lui ai demandé de trouver une condition de concurrence qui nous rendait fous depuis des semaines. Il l’a trouvée en 12 minutes. Explication claire. Trois solutions proposées. Rien que ça, ça valait le coup.

𝐆𝐏𝐓-𝟓.𝟑 𝐂𝐨𝐝𝐞𝐱 𝐞𝐬𝐭 𝐩𝐥𝐮𝐬 𝐫𝐚𝐩𝐢𝐝𝐞, 𝐦𝐚𝐢𝐬…

Le nouveau modèle d’OpenAI est clairement plus rapide pour les petites tâches. Écrire une fonction utilitaire, corriger un bug, générer du boilerplate — ça répond plus vite, c’est plus nerveux.

Ils ont beaucoup insisté sur le fait que le modèle avait été “instrumental dans sa propre création”, ce qui… ok ? Je ne sais pas trop ce que ça change concrètement. Je n’ai pas vu de différence flagrante dans sa manière de déboguer son propre code par rapport à Opus.

𝐌𝐨𝐧 𝐬𝐞𝐭𝐮𝐩 𝐚𝐜𝐭𝐮𝐞𝐥 :

Opus quand je dois travailler sur plusieurs fichiers ou gérer beaucoup de contexte.

𝐂𝐨𝐝𝐞𝐱 𝐩𝐨𝐮𝐫 𝐥𝐞𝐬 𝐭â𝐜𝐡𝐞𝐬 𝐫𝐚𝐩𝐢𝐝𝐞𝐬.

Les deux pour la r***e de code, parce que pourquoi pas — ils repèrent parfois des choses différentes.

𝐋𝐚 𝐩𝐚𝐫𝐭𝐢𝐞 𝐝𝐨𝐧𝐭 𝐩𝐞𝐫𝐬𝐨𝐧𝐧𝐞 𝐧𝐞 𝐩𝐚𝐫𝐥𝐞 𝐯𝐫𝐚𝐢𝐦𝐞𝐧𝐭

Deux jours avant ces sorties, les actions de sociétés de logiciels ont perdu 285 milliards de dollars en une seule journée. Thomson Reuters, LegalZoom, plusieurs entreprises européennes — toutes en baisse à deux chiffres.

Pourquoi ? Anthropic a sorti un outil d’automatisation juridique et les investisseurs ont paniqué : “ces boîtes vont se faire démonter”.

Pendant ce temps, le produit Claude Code d’Anthropic a atteint 1 milliard de dollars de revenus annuels. Six mois après son lancement.

Donc les entreprises qui fabriquent les outils d’IA gagnent des sommes délirantes. Celles dont les produits risquent d’être remplacés voient leur valorisation s’effondrer. Ce n’est pas de la science-fiction, c’est maintenant.

𝐋𝐞 𝐜𝐨𝐧𝐜𝐞𝐩𝐭 𝐝𝐞 “𝐯𝐢𝐛𝐞 𝐰𝐨𝐫𝐤𝐢𝐧𝐠”

Scott White, chez Anthropic, a dit un truc intéressant dans une interview CNBC. Il a parlé de “vibe working” — en référence au “vibe coding”, où tu décris ce que tu veux et l’IA le construit.

Son idée : Opus 4.6 n’est plus seulement pour les développeurs. Ils voient des chefs de produit, des analystes financiers, plein de profils utiliser Claude Code parce qu’il est juste efficace pour faire des tâches : feuilles Excel, recherche, présentations.

Je ne sais pas trop quoi en penser. D’un côté, c’est cool : plus de gens peuvent faire plus de choses. De l’autre… qu’est-ce qu’il reste aux humains si l’IA gère le tableur, la r***e de code et la présentation trimestrielle ?

Les VCs interrogés par TechCrunch cette semaine étaient assez cash. Un gars de Battery Ventures a dit que 2026 serait l’année où l’IA passerait de “rendre les humains plus productifs” à “automatiser directement le travail”.

C’est… beaucoup à encaisser.

Ce que je fais concrètement avec tout ça

𝐌𝐨𝐧 𝐰𝐨𝐫𝐤𝐟𝐥𝐨𝐰 𝐡𝐨𝐧𝐧ê𝐭𝐞 𝐚𝐮𝐣𝐨𝐮𝐫𝐝’𝐡𝐮𝐢 :

Grosses tâches (refactor, compréhension d’une nouvelle base de code, bugs complexes) : Opus 4.6.

Petites tâches rapides : Codex.

R***e de code : les deux, sans hésiter.

Équipes d’agents : encore en test. Prometteur, mais pas encore assez fiable pour tourner sans supervision sur quelque chose de critique.

𝐀𝐥𝐨𝐫𝐬, ç𝐚 𝐯𝐞𝐮𝐭 𝐝𝐢𝐫𝐞 𝐪𝐮𝐨𝐢 ?

Je ne pense pas que l’un ou l’autre ait “gagné” cette semaine. Le drama des 15 minutes sera oublié dans un mois.

Ce qui ne sera pas oublié, c’est qu’on est clairement entrés dans une nouvelle phase. Ce ne sont plus des chatbots qui aident à écrire du code. Ce sont des systèmes capables de faire du vrai travail sur de grosses bases de code, de se coordonner entre eux et de fonctionner longtemps sans qu’on les tienne par la main.

Si tu codes pour vivre, la question n’est plus “est-ce que je dois utiliser ça ?”. C’est : quelles parties de ton job restent vraiment les tiennes ? Ceux que je vois bien s’en sortir sont ceux qui savent où leur jugement compte encore — décisions d’architecture, compréhension des vrais besoins utilisateurs, dynamique d’équipe. Des choses que l’IA ne voit pas.

Si tu construis un produit, il faut sérieusement se demander si ton business peut survivre quand des agents de code compétents coûtent quasiment rien. Beaucoup de SaaS, au fond, c’est “on a automatisé ce workflow pour vous”. Sauf que maintenant, l’utilisateur peut juste demander à Claude de faire le workflow directement.

Voilà ma lecture de la semaine. Je continue de tester, comme tout le monde, et d’essayer de comprendre où ça nous mène.

Si tu joues avec l’un de ces modèles, je suis curieux de savoir ce que toi tu observes.

Source : https://x.com/ParasMadan9/status/2020823217464828218

☕ 𝐋𝐞 𝐕𝐫𝐚𝐢 𝐂𝐲𝐜𝐥𝐞 𝐝𝐞 𝐕𝐢𝐞 𝐝𝐮 𝐃𝐞́𝐯𝐞𝐥𝐨𝐩𝐩𝐞𝐮𝐫 : 𝐃𝐨𝐫𝐦𝐢𝐫 --> 𝐂𝐚𝐟𝐞́ --> 𝐂𝐨𝐝𝐞𝐫 (𝐞𝐭 𝐥'𝐨𝐩𝐭𝐢𝐦𝐢𝐬𝐞𝐫 !)

𝘚𝑎𝘭𝑢𝘵 𝘭'𝘦́𝑞𝘶𝑖𝘱𝑒 ! 𝑂𝘯 𝘢 𝘵𝑜𝘶𝑠 𝑐𝘰𝑛𝘯𝑢 𝑐𝘦 𝘤𝑦𝘤𝑙𝘦 𝘪𝑛𝘵𝑒𝘯𝑠𝘦. 𝑀𝘢𝑖𝘴 𝘴𝑎𝘷𝑖𝘦𝑧-𝑣𝘰𝑢𝘴 𝘲𝑢𝘦 𝘮𝑎𝘭 𝘨𝑒́𝘳𝑒́, 𝘪𝑙 𝑛𝘰𝑢𝘴 𝘮𝑒̀𝘯𝑒 𝑑𝘳𝑜𝘪𝑡 𝑎𝘶 𝘤𝑟𝘢𝑠𝘩 𝘦𝑡 𝑎𝘶 𝘤𝑜𝘥𝑒 𝑠𝘱𝑎𝘨ℎ𝘦𝑡𝘵𝑖 🍝 ?

𝘗𝑜𝘶𝑟 𝑡𝘳𝑎𝘯𝑠𝘧𝑜𝘳𝑚𝘦𝑟 𝑐𝘦 𝘤𝑦𝘤𝑙𝘦 𝘦𝑛 𝑠𝘶𝑝𝘦𝑟-𝑝𝘰𝑢𝘷𝑜𝘪𝑟, 𝘷𝑜𝘪𝑐𝘪 𝘭𝑒 𝑠𝘦𝑐𝘳𝑒𝘵 𝘥𝑒𝘴 𝘱𝑟𝘰𝑠 :

💤 𝙀́𝙩𝙖𝙥𝙚 1 : 𝙇𝙚 𝙎𝙤𝙢𝙢𝙚𝙞𝙡 𝙎𝙖𝙘𝙧𝙚́ (7𝙝-9𝙝)

𝘓𝑎 𝑞𝘶𝑎𝘭𝑖𝘵𝑒́ 𝑑𝘶 𝘴𝑜𝘮𝑚𝘦𝑖𝘭 𝘪𝑚𝘱𝑎𝘤𝑡𝘦 𝘥𝑖𝘳𝑒𝘤𝑡𝘦𝑚𝘦𝑛𝘵 𝘷𝑜𝘵𝑟𝘦 𝘤𝑎𝘱𝑎𝘤𝑖𝘵𝑒́ 𝑎̀ 𝑑𝘦́𝑏𝘶𝑔𝘨𝑒𝘳. 𝑂𝘶𝑏𝘭𝑖𝘦𝑧 𝑙𝘢 𝘭𝑢𝘮𝑖𝘦̀𝑟𝘦 𝘣𝑙𝘦𝑢𝘦 𝘶𝑛𝘦 𝘩𝑒𝘶𝑟𝘦 𝘢𝑣𝘢𝑛𝘵 𝘥'𝘦́𝑡𝘦𝑖𝘯𝑑𝘳𝑒. 𝘝𝑜𝘵𝑟𝘦 𝘤𝑒𝘳𝑣𝘦𝑎𝘶 𝘷𝑜𝘶𝑠 𝑙𝘦 𝘳𝑒𝘯𝑑𝘳𝑎 𝑒𝘯 𝘭𝑖𝘨𝑛𝘦𝑠 𝑑𝘦 𝘤𝑜𝘥𝑒 𝑓𝘭𝑢𝘪𝑑𝘦𝑠 !

☕ 𝙀́𝙩𝙖𝙥𝙚 2 : 𝙇𝙚 𝘾𝙖𝙛𝙚́ 𝙎𝙩𝙧𝙖𝙩𝙚́𝙜𝙞𝙦𝙪𝙚

𝑁𝘦 𝘷𝑜𝘶𝑠 𝑗𝘦𝑡𝘦𝑧 𝑝𝘢𝑠 𝑠𝘶𝑟 𝑙𝘢 𝘮𝑎𝘤ℎ𝘪𝑛𝘦 𝘥𝑒̀𝘴 𝘭𝑒 𝑟𝘦́𝑣𝘦𝑖𝘭. 𝐴𝘵𝑡𝘦𝑛𝘥𝑒𝘻 𝘶𝑛𝘦 𝘣𝑜𝘯𝑛𝘦 𝘩𝑒𝘶𝑟𝘦 ! 𝘌𝑡 𝑠𝘶𝑟𝘵𝑜𝘶𝑡 : 𝑐𝘰𝑢𝘱𝑒𝘻 𝘭𝑎 𝑐𝘢𝑓𝘦́𝑖𝘯𝑒 𝑎𝘱𝑟𝘦̀𝑠 14ℎ ! (𝘖𝑢𝘪, 𝑚𝘦̂𝑚𝘦 𝘤𝑒 𝑝𝘦𝑡𝘪𝑡 𝑒𝘹𝑝𝘳𝑒𝘴𝑠𝘰 𝘥𝑒 𝑙'𝑎𝘱𝑟𝘦̀𝑠-𝑚𝘪𝑑𝘪, 𝑐'𝑒𝘴𝑡 𝑐𝘦 𝘲𝑢𝘪 𝘴𝑎𝘣𝑜𝘵𝑒 𝑣𝘰𝑡𝘳𝑒 𝑠𝘰𝑚𝘮𝑒𝘪𝑙 𝑝𝘳𝑜𝘧𝑜𝘯𝑑.)

💻 𝙀́𝙩𝙖𝙥𝙚 3 : 𝙇𝙚 𝘾𝙤𝙙𝙚 𝘾𝙤𝙣𝙘𝙚𝙣𝙩𝙧𝙚́

𝐿𝘦𝑣𝘦𝑧-𝑣𝘰𝑢𝘴, 𝑚𝘢𝑟𝘤ℎ𝘦𝑧, 𝘦́𝑡𝘪𝑟𝘦𝑧-𝑣𝘰𝑢𝘴. 𝐿𝘦 𝘤𝑜𝘥𝑎𝘨𝑒 𝑒𝘴𝑡 𝑠𝘦́𝑑𝘦𝑛𝘵𝑎𝘪𝑟𝘦. 𝑈𝘯 𝘱𝑒𝘵𝑖𝘵 𝘣𝑟𝘦𝑎𝘬 𝘵𝑜𝘶𝑡𝘦𝑠 𝑙𝘦𝑠 ℎ𝘦𝑢𝘳𝑒𝘴 𝘦𝑠𝘵 𝘷𝑖𝘵𝑎𝘭 𝘱𝑜𝘶𝑟 𝑟𝘦𝑐𝘩𝑎𝘳𝑔𝘦𝑟 𝑙𝘦𝑠 𝑏𝘢𝑡𝘵𝑒𝘳𝑖𝘦𝑠 𝑒𝘵 𝘦́𝑣𝘪𝑡𝘦𝑟 𝑑𝘦 𝘧𝑖𝘹𝑒𝘳 𝘭'𝘦́𝑐𝘳𝑎𝘯 𝘴𝑎𝘯𝑠 𝑟𝘪𝑒𝘯 𝘱𝑟𝘰𝑑𝘶𝑖𝘳𝑒.

𝑂𝘯 𝘦́𝑐𝘩𝑎𝘯𝑔𝘦 𝘭𝑒𝘴 𝘮𝑎𝘶𝑣𝘢𝑖𝘴𝑒𝘴 𝘩𝑎𝘣𝑖𝘵𝑢𝘥𝑒𝘴 𝘤𝑜𝘯𝑡𝘳𝑒 𝑙𝘢 𝘱𝑟𝘰𝑑𝘶𝑐𝘵𝑖𝘷𝑖𝘵𝑒́ 𝑑𝘶𝑟𝘢𝑏𝘭𝑒 ! 💪

𝘙𝑎𝘤𝑜𝘯𝑡𝘦𝑧-𝑚𝘰𝑖 : 𝑎̀ 𝑞𝘶𝑒𝘭𝑙𝘦 𝘩𝑒𝘶𝑟𝘦 𝘣𝑢𝘷𝑒𝘻-𝘷𝑜𝘶𝑠 𝑣𝘰𝑡𝘳𝑒 𝑑𝘦𝑟𝘯𝑖𝘦̀𝑟𝘦 𝘵𝑎𝘴𝑠𝘦 𝘥𝑒 𝑐𝘢𝑓𝘦́ ? 🤫