Classement

Honnêtement, entre faire confiance au code du stagiaire à qui on a donné un projet qu'on avait pas le temps de faire, celui du prestataire à qui on a dit qu'on ne prolongera pas la mission, ou encore celui du dev senior qu'on ne sait même pas comment il est encore dans la boite à copier du code de stack overflow parce qu'il ne sait toujours pas coder un tableau de pointeurs de fonction sans faire de casts partout, l'IA n'est pas pire, loin de là. Comme il a déjà été dit plus haut, le code produit reste de la responsabilité du développeur. C'est lui qui est garant de son livrable. S'il utilise l'IA, c'est à lui de s'assurer que les résultats correspondent aux specs. Après que l'IA fasse if( (a>=0) && (a=<0) ) au lieu de if (a==0), c'est moche, ça ressemble à du code de stagiaire, mais le compilo l'optimise et le résultat est le même. Ce n'est pas pire que lorsque je fais de tête 8x9=8x8+8=64+8=72 parce que je ne me souviens plus que 8x9=72 (j'aime pas les impairs sauf les 5). C'est un exemple exagéré bien sûr. Dans l'autre sens, certains développeurs produisent du code ultra optimisé qui fonctionne mais qui est imbitable. Là t'arrive à la réunion de review, personne n'a rien compris mais comme ça passe les tests unitaires et la validation fonctionnelle, l'avis métier passe au vert. Je connais un spécialiste du genre lorsqu'il s'agit d'écrire des scripts shell Posix. C'est un peu ce que dit l'article, l'IA ne dégrade pas la sécurité, c'est le développeur qui fait trop confiance. Pour moi c'est là que le professionnalisme des devs fait toute la différence. Coder un petit outil de timelapse sans lire le code oui, coder un algorithme de régulation de température qui se retrouve dans les thermostats chez les clients sans tester, non. Je remarque souvent que ce type d'article me fait penser aux comportements des "anciennes" IA. Ceux qui ont l'habitude de jongler entre les modèles remarquent tout de suite la différence entre un GPT-4 et un GPT-5, ou un Claude Sonnet et un Claude Opus. L'ancien modèle est toujours plus c*n que le nouveau.

Voici un article intéressant sur le site Elektor (en accès libre) : 2026 : une odyssée de l’IA — Conséquences du vibe coding En 2025, le « vibe coding » est devenu un véritable flux de travail, pour le meilleur comme pour le pire : je décrivais ce que je voulais, j’acceptais ce que le modèle produisait, je recopiais l’erreur suivante et je recommençais. Le code « fonctionnait », mais je ne l’avais souvent ni lu ni compris (surtout dans un langage que je maîtrise mal). Le terme « vibe coding » a été forgé par Andrej Karpathy dans un billet viral décrivant un mode où l’on « oublie même que le code existe . Simon Willison a ensuite proposé la définition la plus utilisable par les équipes dans les règles internes et en revue de code : le vibe coding consiste à « générer du code avec l’IA sans se soucier du code produit ». Cette attitude peut être rationnelle pour des prototypes et des outils ponctuels. Pensez à de petits modules en boîte noire qui exécutent des tâches simples et semblent le faire correctement - le « j’ai juste besoin que ça fasse ce truc », acceptable pour les makers et les amateurs. Les problèmes apparaissent lorsque ces artefacts « jetables » deviennent des dépendances, des fonctions génératrices de revenus ou des firmwares embarqués à maintenir, auditer et sécuriser pendant des années. Si 2025 a été l’année où tout le monde a livré plus vite, 2026 est celle où beaucoup d’équipes découvrent ce qu’elles ont livré. Ce que signifie le « vibe coding » (et ce que ce n’est pas) Beaucoup d’ingénieurs ont utilisé l’IA en 2025 sans faire du vibe coding : génération de code standard, rédaction de tests, explication d’API nouvelles ou première version ensuite passée en revue. C’est simplement du développement assisté par l’IA. Le vibe coding est le mode où personne n’est responsable du fonctionnement interne. On quitte alors l’outil à la démarche. Traite-t-on la sortie de l’IA comme du code non fiable devant passer revue, tests et contrôles de sécurité comme toute contribution externe ? Ou comme un raccourci qui s’en affranchit ? En pratique, les équipes y glissent par petites décisions raisonnables : un script rapide ici, une couche d’intégration là, une automatisation « temporaire », une migration générée, un workflow CI généré, un module Terraform généré. Chaque élément est plausible isolément. Le résultat global est une base logicielle avec plus d’exposition, plus de dépendances et moins de personnes qui comprennent vraiment pourquoi ça fonctionne. La vitesse a augmenté, la stabilité non Le point de données public le plus frappant est la recherche DORA sur l’adoption de l’IA générative. Dans le résumé du rapport DORA 2024, Google a indiqué qu’à mesure que l’adoption de l’IA augmentait, elle s’accompagnait d’une baisse estimée de 7,2 % de la stabilité de livraison et de 1,5 % du débit de livraison. Le rapport DORA 2025 a présenté ces chiffres comme une variation estimée pour chaque hausse de 25 % de l’adoption de l’IA et a souligné l’écart entre l'impression de rapidité des développeurs et la performance réelle de livraison. Ce schéma correspond exactement à ce que le vibe coding optimise : la vitesse locale plutôt que la fiabilité globale. L’IA réduit le coût des changements, ce qui encourage des modifications plus importants et plus fréquents. Si le discipline de mise en production est déjà fragile, l’IA en amplifie les effets. Il existe aussi une hypothèse moins confortable : l’IA ne fait pas toujours gagner du temps aux développeurs expérimentés sur des bases familières, même si l’impression est contraire. Un essai contrôlé randomisé de METR a montré que des développeurs open source expérimentés prenaient environ 19 % de temps en plus avec des outils d’IA début 2025, tout en se croyant plus rapides. La conclusion n’est pas que « l’IA est mauvaise », mais que « l’intuition n’est pas un indicateur fiable. ». Si un flux réduit la compréhension ou accroît le coût de vérification, la promesse de vitesse peut s’inverser. Défaillances de qualité qui passent bien en démo Le code produit en vibe coding passe souvent des tests superficiels car il est optimisé pour la plausibilité. Il échoue ensuite de façon difficile à diagnostiquer : Colle surajustée : code fragile supposant la forme exacte des entrées, API ou HTML du moment, sans contrats ni versionnement. Complexité cachée : scripts « en un fichier » qui accumulent reprises, cache, concurrence et cas limites jusqu’à devenir des systèmes complets. Dette de performance discrète : requêtes N+1, boucles quadratiques, files non bornées, préchargements ou schémas de cache qui masquent les causes profondes. Risques de configuration : workflows CI/CD, règles IAM cloud, manifestes Kubernetes et modules Terraform qui « fonctionnent » tout en intégrant des valeurs par défaut dangereuses. Théâtre de tests : tests générés qui valident le comportement actuel plutôt que l’intention, ou qui neutralisent le risque réel. Le fil conducteur est l’intention manquante. Les systèmes écrits par des humains gardent une trace du pourquoi. Les systèmes du vibe coding n’ont souvent que le quoi. Sécurité : « ça compile » n’est pas une propriété de sécurité Le vibe coding vise le fonctionnement local immédiat plutôt que la sûreté en environnement hostile. Ce n’est pas théorique. Une étude empirique de fragments générés par l’IA a constaté une forte probabilité de faiblesses de sécurité, notamment de nombreux fragments Python et JavaScript signalés avec des problèmes alignés sur la CWE dans de vrais projets GitHub. Ces études ne condamnent pas un outil en particulier ; l’analyse statique produit des faux positifs et une faiblesse signalée n’est pas toujours exploitable. Mais la tendance est claire : un code plausible n’est pas forcément sûr, et la sécurité est précisément l’exigence non fonctionnelle ignorée par le vibe coding. Les risques les plus fréquents dans les bases très orientées IA restent les classiques : Injection et constructions dangereuses : injection SQL, injection de commandes, désérialisation non sûre, templating fragile et validation d’entrées faible. Fuite de secrets : clés commises dans des scripts « temporaires », journaux contenant des jetons et endpoints de débogage qui passent en production. Erreurs d’authentification et de session : authentification artisanale, contrôles d’autorisation manquants et mauvaise compréhension des frontières d’identité entre services. Pièges cryptographiques : aléa DIY, mauvais modes, mauvaise gestion des clés et valeurs par défaut non sûres qui passent les tests. Le vibe coding n’est pas intrinsèquement dangereux ; il l’est d’une manière précise : il facilite la production de beaucoup de code sans la compréhension nécessaire pour voir les hypothèses de sécurité implicites. Risque de chaîne d’approvisionnement : hallucinations de paquets et attaques via les dépendances Accepter la sortie de l’IA sans la lire fait des dépendances une surface d’attaque majeure. Un risque est l’« hallucination de paquets » : le modèle suggère une dépendance inexistante. Un attaquant peut publier un paquet de ce nom et attendre une installation. USENIX a analysé le phénomène comme une forme de confusion de paquets dans la chaîne d’approvisionnement logicielle. Plus profondément, l’IA fait de « essaie cette bibliothèque » un réflexe. Dans une boucle de vibe coding, ajouter des dépendances paraît moins coûteux que comprendre l’existant. Cela augmente : le nombre de dépendances transitives implicitement approuvées, la vitesse d’entrée de paquets inconnus dans la compilation, et la difficulté d’audit et de correction lors d’un incident de chaîne d’approvisionnement. Pour le code embarqué et industriel, les défaillances sont moins indulgentes Les logiciels web peuvent souvent échouer « en douceur » : dégradation sans dommages physiques immédiats ou permanents. Les systèmes embarqués, eux, échouent plutôt par pannes intermittentes, bugs de temporisation, incidents de sécurité ou blocages irréversibles. Les firmwares issus du vibe coding sont particulièrement sujets à : Détails matériels plausibles mais faux : registres, champs de bits, temporisations et « nombres magiques » incorrects. Risques de concurrence et d’interruptions : conditions de course autour des ISR, DMA, primitives RTOS et tampons partagés, visibles surtout en charge. Mauvais usage des HAL : mélange d’appels HAL et d’écritures directes de registres violant des hypothèses et créant des bugs non reproductibles. Cas limites de protocoles : pilotes I2C/SPI/UART qui passent les tests de bon fonctionnement mais échouent avec l’étirement d’horloge, le bruit, la contention ou des câbles plus longs. Lacunes de watchdog et de reprise : code fonctionnel au labo sans gestion robuste des chutes de tension, du démarrage sûr ou des mécanismes de reprise. Rien de nouveau ici. Ce qui change, c’est la facilité d’entrée du code peu compris et sa longévité tant qu’il « marche à peu près ». Le facteur humain : défiance, surconfiance et dette de compétences Même au pic du battage, la confiance dans la sortie de l’IA n’était pas uniforme. L’enquête Stack Overflow 2025 montrait que davantage de développeurs doutaient de son exactitude qu’ils ne lui faisaient confiance, avec peu de « très confiants &raquo; . La faible confiance ne produit pas forcément une revue attentive. Elle conduit souvent à « relancer la requête jusqu’à ce que les tests passent », une vérification de façade — surtout si les tests sont minces, absents ou générés à partir du comportement actuel. Le coût à long terme va de la dette technique à la dette de compétences. Quand le code devient quelque chose que l’on pilote plutôt que l’on écrit, il reste moins de personnes capables de déboguer au plus bas niveau, de raisonner sur les cas limites et de construire des interfaces fiables. On s’en rend compte quand le système casse hors du périmètre couvert par les tests. La gouvernance rattrape son retard : traiter l’IA comme un contributeur non fiable La réponse pratique qui émerge de 2025 à 2026 est « politique + pipeline », pas « interdiction ». Le profil communautaire SSDF du NIST pour l’IA générative est explicite : tout code source doit être évalué avant usage, sans distinguer entre code humain et code généré&nbsp;. C’est la seule posture qui passe à l’échelle. La question n’est pas « un modèle a-t-il écrit ceci ? » mais « l’accepterions-nous d’un contributeur externe ? ». Un filet de sécurité minimal pour les équipes orientées IA Pour bénéficier de la vitesse de l’IA sans en subir les dérives, il faut poser un cadre minimal. Les outils varient, les principes non. Limiter la taille des modifications. L’IA facilite les gros changements ; la fiabilité les punit. Fixez des limites de PR, déployez par étapes et utilisez des feature flags. Exiger des tests qui échouent utilement. Les tests unitaires ne suffisent pas si les frontières d’intégration sont critiques. Ajoutez des tests de contrat, du fuzzing quand pertinent et des tests de régression liés aux incidents. Activer les scanners et les rendre bloquants. Analyse statique, détection de secrets, analyse des dépendances et scan de conteneurs/IaC doivent être par défaut ; le mode « avertissement » doit être transitoire. Verrouiller les dépendances et tracer la provenance. Lockfiles, versions épinglées, compilations reproductibles, SBOM et artefacts signés sont requis. « Installer le paquet suggéré » n’est pas un processus. Focaliser la revue sur l’intention, pas la syntaxe. Exigez une courte note expliquant la raison, les risques et les tests. Instrumenter la production. L’IA déplace l’effort vers le débogage. L’observabilité est indispensable : journaux, métriques, traçage et SLO explicites. Rien de tout cela n’est nouveau. L’IA accroît simplement la pression sur ces fondamentaux en réduisant le coût marginal du changement. Juridique et conformité : la provenance ne disparaît pas Le vibe coding heurte la conformité en brouillant la provenance : données sources, contraintes de licence et responsabilité. Les régulateurs avancent. La Commission européenne a publié le 10 juillet 2025 un Code de bonnes pratiques pour l’IA à usage général, outil volontaire pour démontrer la conformité aux obligations de l’AI Act applicables dès le 2 août 2025a>. Au Royaume-Uni, une consultation gouvernementale a posé explicitement le droit d’auteur et l’entraînement de l’IA comme problème actif ; elle s’est tenue du 17 décembre 2024 au 25 février 2025. Implication pratique : si votre organisation a des contraintes de licence ou de conformité, le code généré par l’IA ne les contourne pas. Traitez la provenance comme une exigence opérationnelle, pas comme un débat théorique à remettre à plus tard. La vraie leçon de 2025 2025 a réduit le coût de création des logiciels. Pas celui de leur possession. Les équipes qui ont cantonné le vibe coding au prototypage ont gagné en vitesse. Celles qui ont laissé le vibe coding entrer en production en ont subi les conséquences, sous trois formes. Plus d’instabilité, la vélocité dépassant la discipline de livraisona>. Plus d’exposition sécurité, un code plausible n’étant pas sûr et les erreurs de dépendances devenant plus faciles à introduirea>. Plus d’ambiguïté de responsabilité, les questions de provenance, de revue et de licence arrivant plus tard — souvent quand l’argent est en jeu. Rien de tout cela n’implique d’abandonner l’IA. Cela appelle une position simple et juste : l’IA accélère l’ingénierie, elle ne la remplace pas.

Whaou ! C'est la pointe des imprimantes 3D grand public de l'époque. Et depuis il y a eu un grand pas. Un peu comme pour cette "magnifique" version du logo "LesImprimantes3D.fr" utilisée pour taguer les photos. Il me semble que je ne l'avais pas encore vue.

Vu au Fab Lab aujourd'hui. Je ne vais peut-être pas essayer de la remettre en route

Je ne comprends pas L'intérêt de passer sur une hotend Bontech en regardant les tarifs. Vous achetez une hotend à 156$ pour pouvoir changer de buse à 30$. Chez BBL la hotend est à 17€.

C'est marrant, pas plus tard que ce matin, ma femme me montrait des photos de la Printrbot, une imprimante qu'elle avait gagné lors d'une visite scolaire avec sa classe au tout premier 3D Print Show

Merci pour l'info, je vais aller tester ce MOSFET avec un tuto Youtube. Merci @PPAC c'est effectivement la même carte mère. J'ai testé le MOSFET en question il semble bien y a voir un souci, j'ai un BIP (de court circuit) lors d'une étape du test où il ne devrait rien se passer. Bon je ne vais pas me lancer dans la soudure surtout quand je vois la colle qui a été mise sur les connectiques, je sens la grosse galère arriver ! Changer de carte mère ? Déjà pareil faut retirer la colle, après environ 40 balles... Je sais pas quoi ! En tout cas merci pour votre aide !

bonjour a tous les makers alors voila il y a un bon moment que j'ai fait ses boite de deck avec l'aide d'une personne soit ici ou alors sur la page facebook de alphawise je ne sais plus trop elles ont était modéliser sur fusion 360 à l'époque enregistré sur le cloud mais je n'est plus accès a fusion car mon adresse mail de l’époque n'est plus valide . et je crois que le cloud a changer et certain fichier peuvent être perdu enfin bref . je ne trouve plus non plus les image png des logo que j'ai inséré dans les modèles . est ce qu'une âme charitable pourrait m'aide a m’expliquer comme refaire cela sur freecad merci ps: en attendant je vais continuer mes recherche sur le net . voici comment ce présente la boite

Superbe présentation de la CC2, très complètes, cela me donne confiance dans l'utilisation de certain filament. J'ai déjà 100h d'impression sur la mienne, mais uniquement PLA et PETG sans aucun soucie, je vient d'une bonne imprimante la Neptune 4 plus mais la CC2 est bien mieux plus de réglage du Z offset, mais je pence que Elegoo doit encore travaille sur le soft, il me manque personnellement l'affichage de la géométrie du lit d'impression en plus de ce que tu a signalé. Pour Asa, je pense mettre ce type de chauffage: https://www.atome3d.com/products/biqu-panda-breath?variant=57679975416189

Salut la team, donc voilà le résultat après un nombre d'essais incalculable, je suis parvenu à réaliser ma pièce en PPA-CF. paramètres utilisés sur la bambu lab H2S : -Le plateau "smooth noir tout lisse", ultra propre, dégraissé à l'alcool puis à l'acétone. merci pour l'info "PPAC" -un bon coup de 3DLAC, puis la température a 120° -Toutes les avances à 40 mm/s, je sais l'impression dure une plombe mais c'est comme ça. -La buse en 0.4 durci flux standard nickel, température recommandée par le fabricant du filament et de 280° MINIMUM. Non, je suis descendu à 250°, résultat nickel. Je pense que l'on pourrait aller jusqu'à 240° mais à tester. -La chambre a 65° et surtout ne jamais ouvrir la porte, jamais, jamais, jamais. sinon ""warping instantané"" -La bobine de PPA-CF doit être ultra chaude et 70° MINIMUM, puis 24h de séchage et continuer pendant l'impression. INFO importante : le filament est très rigide. Il est recommandé de modifier l'arrivée du fil à l'extrudeur sinon il risque de se coincer.

Merci ! J'ai pris environs une heure à monter l'imprimante avant de tourner en rond car je trouvais plus le petit couvercle.... Pour ce qui est de la tête à quatre filament c'est là où j'ai peiné... Surtout qu'Elegoo avait oublié le bon câble donc j'ai du me débrouiller et il manquait la clé pour un type de vis... Elle imprime très bien mais certaines bobines commandées n'ont pas le RFID alors que c'est de l'elegoo... J'ai eu trois impressions foutues mais ça c'est la faute à la solidité d'une des pattes du cheval qui se cassait dès qu'on retirait les supports... Problème certainement du côté du créateur.. Bien que trouvé sur nexprint...

Je vais surement commander la BIGTREETECH SKR Mini E3 V3.0 Je préfère la garder en vie plutôt que d'en acheter une neuve Et merci pour l'aide

Merci pour la réponse je viens de faire le lien avec un details que j'avais oublié, le câble n'étais plus brancher à l'extrudeur donc j'en conclu que le driver est HS...

J'ai pris cette petite planche à découper, car c'est le truc que j'avais sous la main. Le problème avec le bambou ce sont les fibres très visibles et les variations de teintes. Comme porte-clé c'est sympa à condition d'avoir d'immenses poches.

Salut @Zetif j'ai également un tour du type RC machine RC6123B avec un moteur 1Kw en tri ; j'ai également réalisé un système de pas à Gauche et à droite débrayable. Le montage m'intéresse je vais suivre ton poste J'ai vu le montage du NEMA il est très puissant et pas facile à caser ! A+ Francis ;

Bonsoir, Dans Bambu Studio, ça s'appelle bordure (onglet "Autre").

Ce n'est pas forcément mieux avec un vrai frère.

Faux frère

Je pencherai pour un porte-clés

Splendide, si c'est une planche à découper, cela ne va pas être facile à nettoyer !!!

Tu as encore de belles années devant toi C'est pour ça que l'impression 3D est parfaite pour nous les retraités/seniors/vieux/personnes âgées... Car ça nous oblige à réfléchir et apprendre de nouvelles choses, il faut bien sûr être passionné et effectivement ça empêche le déclin cognitif encore que lorsque ça arrive on ne s'en aperçois pas J'ai comme exemple ma mère de 94 ans qui vit seule chez elle, tant qu'elle est dans son environnement habituel tout va bien (ou presque ) mais le jour où quelque chose change c'est la cata, sa télé est tombée en panne je lui en ai acheté une autre mais là télécommande n'était pas identique et bien elle ne pouvait pas s'habituer et cela malgré tous mes efforts pour lui expliquer, heureusement j'ai réussi à lui trouver une autre télécommande compatible pratiquement identique à l'ancienne et là tout est revenu à la normale