Profile picture of Elodie TURLIER
Elodie TURLIER
Accélérez vos projets tech avec l’IA | Structuration, delivery, automatisation | Fondatrice de Wasteland Studio
Follow me
Generated by linktime
March 28, 2025
10 fausses croyances qu’on entend (encore) quand une entreprise veut “mettre de l’IA” (𝘚𝘱𝘰𝘪𝘭𝘦𝘳 : 𝘱𝘦𝘳𝘴𝘰𝘯𝘯𝘦 𝘯𝘦 𝘴𝘢𝘪𝘵 𝘷𝘳𝘢𝘪𝘮𝘦𝘯𝘵 𝘤𝘦 𝘲𝘶𝘦 𝘤̧𝘢 𝘷𝘦𝘶𝘵 𝘥𝘪𝘳𝘦, 𝘮𝘢𝘪𝘴 𝘵𝘰𝘶𝘵 𝘭𝘦 𝘮𝘰𝘯𝘥𝘦 𝘦𝘯 𝘱𝘢𝘳𝘭𝘦.) 1️⃣ "𝗢𝗻 𝗻’𝗮 𝗾𝘂’𝗮̀ 𝗺𝗲𝘁𝘁𝗿𝗲 𝗱𝗲 𝗹’𝗜𝗔." 👉 Tu sens que le projet va être solide quand ça commence par une phrase digne de “On n’a qu’à créer une app”. 2️⃣ "𝗟’𝗜𝗔 𝘃𝗮 𝘁𝗼𝘂𝘁 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝘀𝗲𝗿." 👉 Bien sûr. Même les bugs… et les décisions absurdes. 3️⃣ "𝗢𝗻 𝘃𝗮 𝗲𝗻𝘁𝗿𝗮𝗶̂𝗻𝗲𝗿 𝗻𝗼𝘁𝗿𝗲 𝗽𝗿𝗼𝗽𝗿𝗲 𝗺𝗼𝗱𝗲̀𝗹𝗲." 👉 C'est sur, avec 12 tickets Jira incomplets, 3 Google Sheets bancales et un tableau Trello nommé “IDEES - copier SVP”. 4️⃣ "𝗖𝗵𝗮𝘁𝗚𝗣𝗧 𝘃𝗮 𝗲́𝗰𝗿𝗶𝗿𝗲 𝗹𝗲𝘀 𝗺𝗮𝗶𝗹𝘀, 𝗹𝗲𝘀 𝘀𝗽𝗲𝗰𝘀 𝗲𝘁 𝗹𝗲𝘀 𝗽𝗿𝗲́𝘀𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻𝘀." 👉 Oui, et il peut aussi écrire une chanson de rap sur la roadmap. Le feu. 5️⃣ "𝗖’𝗲𝘀𝘁 𝗽𝗮𝘀 𝗴𝗿𝗮𝘃𝗲 𝘀𝗶 𝗰’𝗲𝘀𝘁 𝗳𝗹𝗼𝘂, 𝗽𝗮𝘀 𝗯𝗲𝘀𝗼𝗶𝗻 𝗱𝗲 𝘁𝗼𝘂𝘁 𝗰𝗮𝗱𝗿𝗲𝗿, 𝗹’𝗜𝗔 𝘃𝗮 𝗰𝗼𝗺𝗽𝗿𝗲𝗻𝗱𝗿𝗲 𝗹’𝗶𝗻𝘁𝗲𝗻𝘁𝗶𝗼𝗻." 👉 C'est sur, contrairement à nous, elle adore bosser sans contexte, sans données et avec 4 objectifs contradictoires. C’est beau cette foi en la technologie. Vraiment. Presque spirituel. 6️⃣ "𝗢𝗻 𝗺𝗲𝘁𝘁𝗿𝗮 𝘂𝗻 𝗮𝘀𝘀𝗶𝘀𝘁𝗮𝗻𝘁 𝗶𝗻𝘁𝗲𝗹𝗹𝗶𝗴𝗲𝗻𝘁 𝘀𝘂𝗿 𝗹𝗲 𝘀𝗶𝘁𝗲." 👉 Pas parce que c’est utile mais juste parce qu’on a vu que les autres le font. 7️⃣ "𝗖’𝗲𝘀𝘁 𝗱𝗲 𝗹’𝗜𝗔, 𝗱𝗼𝗻𝗰 𝗰̧𝗮 𝗮𝗽𝗽𝗿𝗲𝗻𝗱 𝘁𝗼𝘂𝘁 𝘀𝗲𝘂𝗹." 👉 À ce rythme-là, on va bientôt lui demander de s’auto-debugger en prod. 8️⃣ "𝗖’𝗲𝘀𝘁 𝗹𝗮 𝘁𝗲𝗻𝗱𝗮𝗻𝗰𝗲, 𝗳𝗮𝘂𝘁 𝗽𝗮𝘀 𝗿𝗮𝘁𝗲𝗿 𝗹𝗲 𝘁𝗿𝗮𝗶𝗻." 👉 Même si on sait pas où va le train. Ni s’il y a des rails. Ni s’il est réel. 9️⃣ "𝗢𝗻 𝗻’𝗮 𝗽𝗮𝘀 𝗹𝗲 𝗯𝘂𝗱𝗴𝗲𝘁, 𝗺𝗮𝗶𝘀 𝗼𝗻 𝘃𝗲𝘂𝘁 𝗾𝘂𝗲𝗹𝗾𝘂𝗲 𝗰𝗵𝗼𝘀𝗲 𝗱𝗲 𝘁𝗿𝗲̀𝘀 𝗶𝗻𝘁𝗲𝗹𝗹𝗶𝗴𝗲𝗻𝘁." 👉 Traduction : “On veut que ce soit magique, mais gratuit.” Pas de dev, pas de data, pas de stratégie. Mais beaucoup d’espoir. 🔟 "𝗔𝘃𝗲𝗰 𝗰̧𝗮, 𝗼𝗻 𝘃𝗮 𝗿𝗲́𝘃𝗼𝗹𝘂𝘁𝗶𝗼𝗻𝗻𝗲𝗿 𝗻𝗼𝘁𝗿𝗲 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀." 👉 Jusqu’à présent, ça à surtout révolutionné le nombre de réunions... 📌 𝗟’𝗜𝗔, 𝗮𝘂𝗷𝗼𝘂𝗿𝗱’𝗵𝘂𝗶, 𝗰’𝗲𝘀𝘁 𝘂𝗻 𝗽𝗲𝘂 𝗰𝗼𝗺𝗺𝗲 𝗹𝗲 𝗾𝘂𝗶𝗻𝗼𝗮 𝗱𝗮𝗻𝘀 𝗹𝗲𝘀 𝗰𝗮𝗻𝘁𝗶𝗻𝗲𝘀 𝗱’𝗲𝗻𝘁𝗿𝗲𝗽𝗿𝗶𝘀𝗲 : Tout le monde en parle, personne sait comment le cuisiner, et ça finit par être réchauffé au micro-ondes. Et dans beaucoup d’entreprises… “On veut de l’IA.” “Pourquoi ?” “… Parce que.” 💬 T’as déjà entendu ces phrases ? Balance les pires croyances IA que t’as croisées en commentaire.
Stay updated
Subscribe to receive my future LinkedIn posts in your mailbox.

By clicking "Subscribe", you agree to receive emails from linktime.co.
You can unsubscribe at any time.

18 Likes
March 28, 2025
Discussion about this post
Profile picture of Pierre-Louis Dormont
Pierre-Louis Dormont
Chef de projet IT biomédical | Développement de logiciels médicaux | Innovation MedTech & HealthTech - Biomedical IT Project Manager | Medical Software Development | MedTech & HealthTech Innovation
5 months ago
Il y a eut le même phénomène quand l'essort des sites web est arivé, tout le monde en voulait un mais sans savoir quoi en faire le plus souvent ... La techno change mais pas les comportements
Profile picture of Djilali FEGHOULI, PMP
Djilali FEGHOULI, PMP
🔥Je t'aide à devenir Freelance 🖋8 millions de vues par an j'écris pour les CEO & Indépendants 🧭PMO Freelance
5 months ago
l'IA va remplacer 50% des équipes
Profile picture of laurent Bensoussan
laurent Bensoussan
Développeur FullStack (Java, JS, TS) | Je vous accompagne dans la réalisation de vos MVP en pensant scalable et durabilité
5 months ago
Elodie TURLIER trop bien Homer tourne !! du coup il s'arrête sur un des 10 points 🤣 au hasard
Claude Code comprend ton projet… avant même que tu aies fini la commande. C’est ce que j’ai observé en l’intégrant à mes workflows dev, au fil de plusieurs semaines d’usage réel. Pas une IA gadget ou un clone de GPT en ligne de commande. Un vrai agent local, structuré, que tu pilotes selon ta logique. J’ai tout documenté dans un guide (dispo gratuitement) pour que ce ne soit pas juste bluffant en démo, mais réellement utile en production. Voici ce que tu vas y trouver : → Installation et configuration complète (MCP, sandbox, limitations) → Organisation de la mémoire + stratégie de prompt efficace → Architecture d’usage : Claude comme architecte (plan) → éditeur (act) → Astuces d’optimisation pour éviter les relectures inutiles → Sécurité, personnalisation, séparation des contextes → Cas d’usage testés : refacto, génération ciblée, debug, pattern review → Recommandations si tu bosses en équipe ou sur des projets complexes L’objectif : Ne plus perdre de temps à bricoler une interface IA. Mais intégrer Claude comme un vrai outil dans ta chaîne de production. 𝗖𝗲 𝗴𝘂𝗶𝗱𝗲 𝗷𝗲 𝘁𝗲 𝗹'𝗼𝗳𝗳𝗿𝗲. Pour le découvrir : 1. Ajoute moi en contact si ce n’est pas déjà fait 2. Like ce post 3. Commente "CLAUDE CODE" et je te l’envoie ✌️ 💬 Et si tu l'as lu : dis-moi ce que tu voudrais voir en plus. Je l’améliore en continu, donc tout retour est bienvenu.
2962 comments
August 20, 2025
𝗘𝘁 𝘀𝗶 𝗹𝗮 𝗖𝗹𝗲𝗮𝗻 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗲́𝘁𝗮𝗶𝘁 𝗟𝗔 𝗽𝗶𝘀𝘁𝗲 𝗽𝗼𝘂𝗿 𝗿𝗲𝗻𝗱𝗿𝗲 𝗔𝗻𝗴𝘂𝗹𝗮𝗿 𝗽𝗹𝘂𝘀… 𝗿𝗲𝘀𝗽𝗶𝗿𝗮𝗯𝗹𝗲 ? Je ne parle pas de théorie ou de grand plan d’urbanisation logicielle. Juste d’un test que j’ai lancé sur un projet client. Une envie de structurer différemment. De voir si ça pouvait vraiment changer la donne. J’ai donc tenté une séparation en 3 couches, avec un principe simple : 𝗚𝗮𝗿𝗱𝗲𝗿 𝗹𝗮 𝗹𝗼𝗴𝗶𝗾𝘂𝗲 𝗺𝗲́𝘁𝗶𝗲𝗿 𝗶𝗻𝗱𝗲́𝗽𝗲𝗻𝗱𝗮𝗻𝘁𝗲 𝗱’𝗔𝗻𝗴𝘂𝗹𝗮𝗿. Voilà ce que j’ai mis en place : → 𝗨𝗻 𝗖𝗼𝗿𝗲 (TypeScript pur) → règles métier, modèles, interfaces → 𝗨𝗻𝗲 𝗨𝗜 𝗔𝗻𝗴𝘂𝗹𝗮𝗿 → composants, routes, styles → 𝗗𝗲𝘀 𝗶𝗺𝗽𝗹𝗲́𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻𝘀 → REST, mocks, peu importe, tant que ça respecte les contrats du Core La logique ne “déborde” plus dans les composants. Les tests sont plus stables. Et une feature se génère en quelques clics grâce à une schematic perso : ng generate ./custom-schematics:generate-core-feature Je ne dis pas que c’est la solution. Mais pour l’instant, ça m’a permis de gagner en clarté, en vitesse et en confiance dans le code. Et surtout, ça rend les évolutions beaucoup plus fluides. Pour les curieux, j’ai partagé un petit 𝗲𝘅𝗲𝗺𝗽𝗹𝗲 𝗰𝗼𝗻𝗰𝗿𝗲𝘁 𝗶𝗰𝗶 : 👉 https://buff.ly/4autIGi 💬 Je suis curieuse : 𝗤𝘂𝗲𝗹 𝗱𝗲́𝗰𝗼𝘂𝗽𝗮𝗴𝗲 𝘃𝗼𝘂𝘀 𝘂𝘁𝗶𝗹𝗶𝘀𝗲𝘇 𝗽𝗼𝘂𝗿 𝗴𝗮𝗿𝗱𝗲𝗿 𝘃𝗼𝘀 𝗮𝗽𝗽𝘀 𝗔𝗻𝗴𝘂𝗹𝗮𝗿 𝗺𝗮𝗶𝗻𝘁𝗲𝗻𝗮𝗯𝗹𝗲𝘀 𝗱𝗮𝗻𝘀 𝗹𝗲 𝘁𝗲𝗺𝗽𝘀 ? 𝗩𝗼𝘂𝘀 𝗮𝘃𝗲𝘇 𝘁𝗲𝘀𝘁𝗲́ 𝗱𝗲𝘀 𝗮𝗽𝗽𝗿𝗼𝗰𝗵𝗲𝘀 𝘀𝗶𝗺𝗶𝗹𝗮𝗶𝗿𝗲𝘀 ?
43 comments
May 6, 2025
𝗝’𝗮𝗶 𝘃𝘂 𝘂𝗻 𝗷𝘂𝗻𝗶𝗼𝗿 𝗽𝗹𝗲𝘂𝗿𝗲𝗿 𝗱𝗲𝘃𝗮𝗻𝘁 𝘂𝗻 𝗳𝗶𝗰𝗵𝗶𝗲𝗿 𝗵𝗲𝗹𝗽𝗲𝗿𝘀.𝘁𝘀 Il faisait 2 831 lignes. Et contenait… 143 fonctions. Le pire ? Personne n’était vraiment choqué. Dans beaucoup d’entreprises, le code propre est un mythe. Voici pourquoi : 1️⃣ 𝗟𝗮 𝗱𝗶𝗰𝘁𝗮𝘁𝘂𝗿𝗲 𝗱𝘂 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝘆 Quand tout doit sortir "hier", les bonnes pratiques sont les premières victimes. Le refactoring ? "On verra plus tard." Spoiler : ce "plus tard" n’arrive jamais. 2️⃣ 𝗧𝘂𝗿𝗻-𝗼𝘃𝗲𝗿 𝗲𝘁 𝗲́𝗾𝘂𝗶𝗽𝗲𝘀 𝗵𝗲́𝘁𝗲́𝗿𝗼𝗴𝗲̀𝗻𝗲𝘀 Chaque nouveau développeur ajoute sa touche… sans contexte, sans relecture, sans transmission. À la fin ? Une cacophonie technique. 3️⃣ 𝗗𝗲𝘀 𝘀𝘁𝗮𝗻𝗱𝗮𝗿𝗱𝘀... 𝘀𝘂𝗿 𝗹𝗲 𝗽𝗮𝗽𝗶𝗲𝗿 𝘀𝗲𝘂𝗹𝗲𝗺𝗲𝗻𝘁 Les conventions existent, mais qui les lit ? Qui les met à jour ? Qui les applique ? Réponse : rarement les devs en feu à 2 jours d’une release. 4️⃣ 𝗟𝗮 𝗱𝗲𝘁𝘁𝗲 𝘁𝗲𝗰𝗵𝗻𝗶𝗾𝘂𝗲 : 𝗹’𝗲́𝗹𝗲́𝗽𝗵𝗮𝗻𝘁 𝗾𝘂’𝗼𝗻 𝗻𝗼𝘂𝗿𝗿𝗶𝘁 Chaque raccourci creuse un peu plus. On le sait. On l’accepte. On l’ignore. 5️⃣ 𝗙𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻 𝗰𝗼𝗻𝘁𝗶𝗻𝘂𝗲 𝗻𝗲́𝗴𝗹𝗶𝗴𝗲́𝗲 Clean Architecture, SOLID, TDD ? Pas le temps. Pas de budget. Pas prioritaire. Donc ça reste flou… voire perçu comme un luxe de sénior. 6️⃣ 𝗘𝗺𝗽𝗶𝗹𝗲𝗺𝗲𝗻𝘁 𝗱𝗲 𝗰𝗼𝘂𝗰𝗵𝗲𝘀 𝘁𝗲𝗰𝗵𝗻𝗶𝗾𝘂𝗲𝘀 Un jour tu es sur un framework de 2014, le lendemain tu pilotes 3 APIs externes en mode panique. Tout est collé. Rien n’est pensé ensemble. 7️⃣ 𝗟𝗮 𝘃𝗶𝘀𝗶𝗼𝗻 𝗽𝗿𝗼𝗱𝘂𝗶𝘁 𝗰𝗲𝗻𝘁𝗿𝗲́𝗲 𝘂𝗻𝗶𝗾𝘂𝗲𝗺𝗲𝗻𝘁 𝘀𝘂𝗿 𝗹𝗲𝘀 𝗳𝗼𝗻𝗰𝘁𝗶𝗼𝗻𝗻𝗮𝗹𝗶𝘁𝗲́𝘀 "Ce ticket doit passer." "Ce bug peut attendre." Et le code devient lent, fragile, et toxique. 𝐐𝐮𝐞 𝐟𝐚𝐢𝐫𝐞 𝐝𝐚𝐧𝐬 𝐜𝐞 𝐜𝐡𝐚𝐨𝐬 ? ◾ Rendre les normes vivantes (outillées, commentées, visibles) ◾ Dédier du temps réel à la dette (refacto planifié ≠ dette fantôme) ◾ Organiser la transmission (revues croisées, pair coding, doc vivante) ◾ Encourager les revues de code : Deux paires d’yeux valent mieux qu’une. ◾ Prioriser la montée en compétence (talks, mentors, dojos) ◾ Réserver du temps tech dans chaque sprint (sinon il disparaît) 𝗟𝗲 𝗰𝗼𝗱𝗲 𝗰𝗹𝗲𝗮𝗻, 𝗰𝗲 𝗻’𝗲𝘀𝘁 𝗽𝗮𝘀 𝗱𝗲 𝗹’𝗲𝗴𝗼. 𝗖’𝗲𝘀𝘁 𝘂𝗻𝗲 𝗱𝗲𝘁𝘁𝗲 𝗾𝘂𝗲 𝘁𝘂 𝗰𝗵𝗼𝗶𝘀𝗶𝘀 𝗱𝗲 𝗿𝗲𝗺𝗯𝗼𝘂𝗿𝘀𝗲𝗿… 𝗼𝘂 𝗱𝗲 𝘁𝗿𝗮𝗻𝘀𝗺𝗲𝘁𝘁𝗿𝗲. 💬 Et toi, quel est le bout de code le plus absurde que tu as dû maintenir ?
42 comments
June 22, 2025
Je ne démarre plus aucun projet Angular sans ça. Et je me demande encore comment je faisais avant. Chaque lancement de projet Angular, c’est une aventure : excitante, mais pleine d’embûches. Au début, j’avançais au feeling. Résultat ? Des bases fragiles, des sprints où tout cassait, et une dette technique qui explosait. Alors j’ai tout repris à zéro. J’ai testé, comparé, jeté. Et aujourd’hui, j’utilise ce starter pack personnel, qui transforme chaque idée en produit robuste et scalable : - Angular Material ou Tailwind : pour construire rapidement une interface qui impressionne et fonctionne. - Jest/Vitest + Cypress : pour partir sereinement, avec des tests qui garantissent stabilité et qualité.  - Transloco : pour gérer les textes de votre application (traduction ou non cela permet de gérer plus efficacement le contenu textuel).  - Compodoc + Storybook : parce que documenter, c’est cartographier, et tout le monde gagne du temps (Storybook dépendra de la taille de mon projet et l'utilisation d'une librairie graphique propre au projet). - Source-map-explorer ou webpack-bundle-analyzer : pour identifier les points lourds et optimiser le parcours. - ESLint + Prettier : pour ajouter un peut de rigueur dans le code. - Auto-changelog :  pour garder une trace claire de chaque changement une fois l'application en production. Avec ces outils, mes projets Angular ne sont plus des paris. Ce sont des plans maîtrisés, de l’idée jusqu’à la mise en prod. 💬 Et toi, c’est quoi l’outil indispensable que tu conseilles pour bien lancer un projet ? Dis-moi en commentaire : je cherche encore la pépite que j’aurais oubliée.
30 comments
May 12, 2025