electroremy

Bonjour Merci pour ce test très complet, qui permet aux futurs acheteurs de faire un choix éclairé. Pour l'ABS, il faut chauffer à au moins 50°C, 60°C c'est l'idéal et cela permet d'imprimer d'autres filaments techniques. Mais si tu ajoutes un chauffage supplémentaire, il faut savoir quelle température les composants de l'imprimante vont supporter. Et oui c'est bien d'isoler, car une imprimante en caisson fermée et chauffé mais réalisée avec des matériaux fins ou conducteurs de la chaleur se transformera en petit chauffage d'appoint, et consommera pas mal d'électricité A bientôt

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 » . 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é . 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.

Me concernant, jamais de soucis avec les marques d'eau en bouteille que j'achète (Wattwiller, Salveta) Avant, je buvais l'eau du robinet, des gastro à répétition, mon médecin envisageait même une intervention chirurgicale plus ou moins handicapante Après, si tu vas bien en buvant l'eau du robinet, tant mieux pour toi

J'ai exercé deux mandats de conseiller municipal dans mon village (liste sans étiquette, ce type mandat est bénévole), j'étais dans la commission eau et assainissement. Ces analyses par commune cachent des réalités différentes. D'abord, les analyses ne font pas faites en continu, elles sont ponctuelles. Quand une analyse n'est pas conforme, on ne sait pas depuis combien de jours cela date. On ajuste le dosage de chlore, si besoin on effecute un nettoyage supplémentaire des réservoirs concernés, mais de l'eau non conforme a été distribuée. Ensuite, les analyses ne sont faites qu'à certains emplacements. Si sur le trajet de la canalisation qui alimente ton quartier, il y a un ou plusieurs piquages de logements innocupés (donc avec de l'eau stagnante qui est en contact avec celle qui alimente ton compteur), le résultat peut être très différent. Peu de personnes le savent, mais, à l'échelle d'une commune, les réseaux ne sont pas étanches. On considère que lorsque le taux de fuites est de moins de 20%, le réseau est de bonne qualité (20% de taux de fuite signifie que 20% de l'eau pompée dans la nappe phréatique est perdue dans les fuites). Cela peut sembler choquant, mais les services techniques font ce qu'ils peuvent ; en effet, les longueurs de canalisations à l'échelle d'une commune sont importantes, il y a en permanence de nouvelles fuites à réparer. De plus, certaines fuites sont difficiles à localiser même avec des instruments de mesure modernes. Les travaux peuvent être très couteux notamment lorsque la canalisation est sous une voirie à fort traffic, ou à proximité de bâtiments ou d'autres types de réseaux (gaz, électricité, télécommunications) Les zones de pompage et les réservoirs enterrés peuvent aussi être temporairement contaminés par de l'eau de ruisselement en cas de forte pluies. Quand le temps est sec, et qu'il arrive un gros orage, la pluie va "lessiver" les sols et emporter avec elle les poussières et les polluants. La solution, c'est d'augmenter le dosage de chlore. Le chlore permet d'avoir un taux de bactéries sous les limites légales, mais une eau trop chlorée peut aussi créer des soucis digestifs. Boire par alternance de l'eau non conforme et de l'eau trop chlorée, c'est très agressif pour les personnes avec un système digestif sensible.

Que dire... Je suis né sous Giscard mais je suis plutôt jeune en fait

Cela ne va pas fragiliser l'acier ?

une solution serai d'intercaler entre la pompe à vide et la chambre à vide un déshydrateur avec des absorbants d'humidité ?

C'est bien vrai, et c'est terrible Même avec une accréditation, combien de fois on m'a cassé les pieds quand je venais avec mes boitiers reflex, alors que dans le public, tout le monde photographiait et filmait avec son téléphone Par rapport à ça, je trouve que les gens font l'inverse de ce qu'il faudrait faire... car s'agissant de la vie privée, un smartphone est bien plus dangereux qu'un appareil photo. Car quelqu'un qui utilise un smartphone pour prendre des photos ou des vidéos avec un réseau social va collecter beaucoup plus de données (la photo mais aussi la date et l'heure, la position GPS, la reconnaissance des visages avec identification via le réseau social, ...). Sans compter le fait que la photo ou la vidéo, une fois publiée sur les réseaux sociaux, souvent en direct, est commentée et partagée et devient vite une donnée publique sur laquelle on n'a plus aucune prise... Autre problème plus inquiétant : il est facile de prendre des photos ou de filmer en douce avec un smartphone, en faisant semblant d'utiliser le smartphone pour jouer, aller sur internet ou téléphoner... C'est ça qui est chiant : aujourd'hui, quelque soit l'endroit ou on se trouve, on est au milieu de gens avec un smartphone dans la main, et on ne sait jamais s'ils ne sont pas en train de filmer ou photographier... Je suis bien d'accord... et même pour un tirage de grande taille, on le regarde à une certaine distance Voilà un autre point important. Les fabricants d'appareil photo font la course aux mégapixels, mais les perfomances en basse lumière stagnent un peu... Je préfèrerais avoir un "modeste" 12 ou 20 Megapixels mais avec très peu de bruit en basse lumière plutôt qu'un 50 Mégapixels mais avec plein de bruit. Dès que la lumière manque (ce qui arrive aussi quand on doit prendre en photo des sujets très rapides), le bruit aboutit à une "bouillie de pixels" dès que l'on regarde de près ou que l'on zoom... De plus, ces photos occupent beaucoup d'espace disque. Souvent, en post traitement, pour ces images en basse lumière, je réduit le bruit et ensuite je redimenssionne l'image à 50% voire 25%, j'obtiens la même qualité d'image mais plus propre et qui occupe moins d'espace disque. Oui, le point fort des smartphones c'est le traitement logiciel intégré. Même si les appareils photos ont des firmwares avec des fonctions avancées, ils restent en retrait... Un blogueur testeur d'appareil photo avait dit qu'il aimerai que les prochains boitiers proposent les mêmes fonctions logicielles que les smartphones La retouche par IA peut être utile pour supprimer des obstacles rapidement et proprement, par exemple des câbles électriques ; ou encore, compléter une zone manquant par une texture correspondant à l'arrière plan (pelouse, ciel, ...)

La question de la fiabilité des logiciels ne date pas d'hier. Ce n'est pas un problème de technologie, mais de mathématiques. Les travaux de Kurt Gödel puis d'Alan Turing, avant l'invention du transistor, et même avant les débuts de l'informatique où les ordinateurs fonctionnaient avec des relais puis des tubes à vides, ont démontré qu'il existe des limites théoriques et de sérieuses difficultés sur la possibilité de vérifier qu'un algorithme est juste. Ces limites sont toujours valables aujourd'hui - y compris pour les logiciels "traditionnels", c'est à dire ceux programmés à la main, avec un comportement déterministe. L'IA, c'est, en quelque sorte, "encore pire", car ce n'est par principe non déterministe. L'ensemble de nos ordinateurs et langages de programmation actuels - y compris les modèles dernier cri - sont tous équivalents, d'un point de vue mathématique, à des Machines de Turing Universelles Je vous invite à lire ces deux livres de Roger Penrose où il explique en détail ces différents aspects : L'esprit, l'ordinateur et les lois de la physique Les ombres de l'esprit - À la recherche d'une science de la conscience Pour dépasser ces limites, nous avons besoin... d'une avancée mathématique. Ce n'est pas une question de quantité de mémoire vive ou de quantité de données collectées pour entrainer les modèles de langage.

L'étude de la fiabilité de la sécurité des machines fait partie de mon travail. Il est déjà très difficile de gérer une fonction de sécurité avec un logiciel traditionnel (programmation procédurale classique). En industrie, les contraintes imposées pour les systèmes de commande qui gèrent des fonctions de sécurité sont sévères, tant sur le software que sur le hardware. Un responsable de l'INRS était intervenu récemment pour expliquer qu'une IA ne devait pas intervenir dans une fonction de sécurité. L'IA pourra intervenir dans le process - c'est d'ailleurs déjà le cas depuis de nombreuses années, avec la vision par ordinateur, très utilisée en industrie - mais pour les fonctions de sécurité, il faudra que ce soit une technologie fiable et éprouvée qui soit prioritaire sur l'IA.

Je pense que c'est plus vicieux Un sac en plastique pourrait, comme le filament, absorber l'humidité, tout en restant étanche et en apparence sec. L'humidité va aussi être absorbée par le filament à l'intérieur du sac. C'est quelque chose qui se produit lentement, et de manière invisible.

C'est plus subtile que ça... D'après ce que j'avais compris, l'humidité peut arriver à franchir progressivement le sac, mais pas l'air Je laisser les spécialistes répondre comme @pjtlivjy

Voilà une remarque très pertinente. Le soucis ce sont les "effets de mode". On veux utiliser l'IA pour être dans le coup... alors qu'il faudrait évaluer si c'est réellement bénéfique ou pas pour l'usage concerné. C'est valable dans beaucoup de domaines, comme la mode du "zéro papier". Le numérique c'est très utile pour plein de choses, mais il y a des cas de figure où un document papier reste plus pratique, plus efficace et/ou plus sûr. Idem pour la mécanique. Personne ne conteste l'utilité des machines CNC et des imprimantes 3D, mais les machines conventionnelles (perceuse à colonne, scie circulaire de table, ...) ça reste utile voire indispensable dans pas mal de cas.

Le gros problème, c'est qu'on utilise l'IA pour donner moins de temps aux gens pour faire leur travail... Ca, je n'arrête pas de le rappeler : les résultats générés par l'IA doivent être vérifiés. Le temps gagné à faire faire quelque chose par l'IA peut être perdu en grande partie par le temps requis pour les vérifications...

Une erreur d'IA conduit à l'emprisonnement d'une grand-mère innocente pendant des mois : la police s'est servie de la reconnaissance faciale dans une affaire de fraude sans vérifier l'alibi Angela Lipps, 50 ans, n'avait jamais mis les pieds dans le Dakota du Nord. Elle n'avait jamais pris l'avion de sa vie. Pourtant, en juillet 2025, une équipe de marshals américains l'a arrêtée à son domicile du Tennessee, pistolet au poing, pendant qu'elle gardait quatre jeunes enfants. La cause : un logiciel de reconnaissance faciale déployé par la police de Fargo avait désigné cette grand-mère de cinq petits-enfants comme la principale suspecte d'une série de fraudes bancaires. Six mois de détention, une maison perdue, une voiture saisie, un chien abandonné... et toujours aucune excuse de la part des autorités. L'affaire Lipps est devenue en quelques jours le symbole mondial des dérives de l'intelligence artificielle dans la justice pénale. Le 14 juillet 2025, Angela Lipps se retrouve soudainement confrontée à des agents armés à la porte de sa maison dans le Tennessee rural. Elle est immédiatement placée en détention provisoire en tant que fugitive de la justice de l'État du Dakota du Nord, un statut qui lui interdit toute mise en liberté sous caution. Elle est incarcérée dans la prison du comté de Macon, dans le Tennessee, pendant près de quatre mois, sans que quiconque de la police de Fargo ne prenne la peine de la contacter ou de l'interroger. Le dossier à l'origine de cette arrestation remonte au printemps 2025. Entre avril et mai, des enquêteurs de Fargo suivent une série d'escroqueries bancaires organisées : une femme utilise une fausse carte d'identité militaire de l'armée américaine pour retirer des dizaines de milliers de dollars dans plusieurs établissements de la région métropolitaine de Fargo. Pour identifier la suspecte filmée par les caméras de surveillance, la police recourt à un logiciel de reconnaissance faciale. Le résultat : Angela Lipps. Un détective complète ensuite l'analyse en consultant ses réseaux sociaux et sa photo de permis de conduire du Tennessee, avant de conclure dans son rapport de mise en cause qu'elle « semble être la suspecte au regard de ses traits du visage, de son type corporel et de la couleur et du style de ses cheveux ». Ce seul faisceau visuel, sans vérification d'alibi ni entretien téléphonique, débouche sur un mandat d'arrêt et l'extradition de la suspecte. 108 jours sans être interrogée, 157 jours de détention totale Ce n'est que le 30 octobre 2025, soit 108 jours après son arrestation dans le Tennessee, que des agents du Dakota du Nord viennent la chercher pour la conduire à Fargo. Elle comparaît le lendemain matin devant un tribunal du comté de Cass. C'est à ce moment-là que l'avocat Jay Greenwood prend sa défense. Sa stratégie est aussi simple qu'implacable : demander les relevés bancaires de sa cliente. Les relevés bancaires montrent qu'elle se trouvait à plus de 1 900 kilomètres de Fargo, chez elle dans le Tennessee, au moment précis où la police affirmait qu'elle commettait des fraudes à Fargo. Ses transactions de la période incriminée racontent une vie ordinaire et sédentaire : encaissement de chèques de sécurité sociale, achat de cigarettes dans une station-service locale, commande de pizza, paiement d'une course Uber Eats via Cash App. Autant de preuves géolocalisées et horodatées qui rendaient physiquement impossible sa présence à Fargo. Ces éléments, que n'importe quel enquêteur aurait pu et dû vérifier en quelques heures, n'avaient jamais été consultés avant l'arrestation. Le 19 décembre 2025, lors d'une rencontre à la prison du comté de Cass, la police de Fargo prend connaissance de ces preuves. C'est la première fois qu'un enquêteur de Fargo parle à Angela Lipps depuis le début de l'affaire. Cinq jours plus tard, le 24 décembre, les charges sont abandonnées et elle est libérée. Elle se retrouve à Fargo, par une nuit de Noël, en vêtements d'été, sans manteau, sans argent, dans la neige. Des avocats de la défense locaux lui paient une chambre d'hôtel et des repas pour les deux jours de fête. Le lendemain de Noël, Adam Martin, fondateur de l'association F5 Project (qui vient en aide aux personnes touchées par l'incarcération), la conduit en voiture jusqu'à Chicago pour qu'elle puisse rentrer chez elle dans le Tennessee. Pendant ses six mois de détention, Angela Lipps n'a pu honorer aucune de ses charges : elle a perdu son logement, sa voiture, et son chien a dû être confié ailleurs. Le chef de la police prend sa retraite sans répondre L'affaire a éclaté dans les médias le 11 mars 2026, grâce aux reportages de la chaîne locale WDAY, qui a obtenu le dossier de police par une demande d'accès aux documents officiels. Le lendemain, le chef de la police de Fargo, David Zibolski, annonçait sa retraite lors d'une conférence de presse. La coïncidence de calendrier n'a pas manqué d'interpeller les journalistes. Le maire de Fargo, Tim Mahoney, contacté par WDAY, n'a pas répondu aux questions sur un éventuel lien entre la retraite de Zibolski et l'affaire Lipps. À la conférence de presse de départ du chef, un journaliste lui a posé la question directe : « Pourquoi personne de la police de Fargo n'a-t-il jamais parlé à Angela Lipps pendant les cinq mois où elle était en prison ? » La réponse de Zibolski : « Merci pour cette question, Matt, mais nous ne sommes pas ici pour parler de ça aujourd'hui. » La police de Fargo n'a présenté aucune excuse à Angela Lipps. La vraie auteure des fraudes, elle, court toujours : l'affaire de fraude bancaire reste ouverte et aucune arrestation n'a été effectuée à ce jour.