Sébastien Dinot a écrit 73 commentaires

Lorsqu'on part d'une formation générale, scientifique ou informatique, le métier d'enseignant me semble bien plus accessible que le métier d'agriculteur, qui demande une somme de savoirs et de savoir-faire qu'imagine mal le commun des mortels.

Dans la même veine, mon beau-père était ébéniste d'art. Ce métier demande de l'habileté et de la créativité, il me semble noble. Cela le rend très attractif à mes yeux. Cerise sur le gâteau, il n'est même pas nécessaire d'avoir le bac pour l'exercer. Pour autant, si mon beau-père, qui était ébéniste d'art, a commencé à travailler alors qu'il n'avait pas encore 14 ans, il lui a fallu de longues années d'apprentissage et d'expérience avant de devenir l'ébéniste accompli et recherché qu'il était. On ne s'improvise pas plus ébéniste d'art qu'agriculteur.

Par contre, détail confortable pour un informaticien, les ciseaux et gouges qu'il utilisait à la fin de sa carrière étaient en tous points semblables à ceux qu'il utilisait au début de sa carrière. Ses outils étaient stables, seules son expérience et son savoir-faire se sont affinés au fil des ans. Quel bonheur que de ne pas connaitre la version moderne du mythe de Sisyphe qu'est le métier d'informaticien : devoir jeter ses outils sitôt ceux-ci maitrisés pour apprendre à en utiliser de nouveaux…

Il y a des étapes que je vois mal remplacées par une IA en l'état actuel mais il est évident que l'IA aurait considérablement réduit l'effectif des projets dont je parle.

Il existe aujourd'hui des IA génératives dont la mission n'est pas de générer du code, mais des architectures.

Je conviens volontiers de trois choses :

1. Si le corpus d'entrainement n'existe pas, il est difficile d'entrainer une IA.

2. Le travail créé par une IA reste perfectible et peut nécessiter des reprises importantes par un humain.

3. Les IA semblent ne savoir créer que par interpolation, pas par extrapolation (par conception, elles restent dans leur cadre de référence que constitue leur jeu de données d'apprentissage ; si cela leur assure une certaine pertinence, cela les enferme aussi).

Mais aucun de ces éléments ne me semble invalider mon inquiétude (et non mon affirmation, puisque, je le rappelle, le titre de ma dépêche était une question) :

1. Les entreprises et les établissements publics se dotent de plus en plus d'IA privées, qu'ils alimentent par des corpus qui leur sont propres et ne sont pas sur la place publique. Si le commun des mortels n'a pas accès à un gros volume de code COBOL, il en va différemment pour une banque.

2. Étant développeur à la base, je suis bien placé pour savoir que la compétence la mieux partagée par l'ensemble des développeurs est la création de bogues et de code perfectible. Tout comme une IA. Et nous avons tous vu notre code repris ou réécrit par un collègue ou contributeur plus expérimenté, quand celui-ci ne nous a tout simplement pas demandé de revoir notre copie, en nous fournissant des instructions plus précises. On a repris mon code, puis j'ai repris le code d'autres personnes, et il arrive encore que des collègues reprennent les rares fragments de code que j'écris aujourd'hui. C'est le travail quotidien. La seule différence avec l'IA, c'est que les derniers LLM publiés (par exemple Claude Opus 4.6) le font à une vitesse fulgurante et qu'ils « apprennent » très vite. L'itération se fait à un rythme bien plus rapide et même si OpenAI ou Anthropic multipliaient leurs tarifs par 5, ils resteraient compétitifs par rapport au cout des développeurs occidentaux. Tout le monde ne peut pas encore se payer l'infra de Stripe, mais quand je lis des articles tels que ceux-ci, je suis pris de vertige (et de gros doutes) :

   • https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents
   • https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2

3. Sans doute aurons-nous toujours besoin d'humains pour terminer le travail et prendre en charge les aspects les plus exploratoires, mais ces humains seront à coup sûr bien moins nombreux qu'ils ne le sont aujourd'hui.

Bref, la rédaction de spécifications fonctionnelles solides et non ambigües me semble être une compétence promise à un meilleur avenir que le développement.

Dire que l’économie du logiciel est morte car on peut créer un logiciel from scratch avec un LLM.
C’est aussi ridicule que de dire les logiciels libres, c’est le cancer des éditeurs de logiciels.

Désolé, en toute honnêteté, je ne vois pas le parallèle et en quoi il serait ridicule de s'inquiéter du fait qu'un LLM abatte en quelques jours un travail réalisé autrefois par des développeurs compétents en quelques mois ou années.

Les premières victimes de cette révolution vont être les ESN. Rappelons leur modèle :
* Le client rédige les spécifications du logiciel.
* Il confie le développement à l'ESN, qui active une cohorte de développeurs.
* Il valide le logiciel livré via un cahier de recette fonctionnelle.
* Il confie à l'ESN la maintenance corrective et évolutive du logiciel.

Avec les IA, le scénario change un peu :

Au mieux (pour l'ESN) :
* Le client rédige les spécifications du logiciel.
* Il confie le développement à l'ESN, qui active une IA et un « prompt engineer/ reviewer »
* Il valide le logiciel livré via un cahier de recette fonctionnelle.
* Il confie à l'ESN la maintenance corrective et évolutive du logiciel, qui réactive la même IA et le même « prompt engineer / reviewer »

Au pire (pour l'ESN) :
* Le client rédige les spécifications du logiciel.
* Il embauche un « prompt engineer/ reviewer »
* Il lui confie le développement du logiciel via l'IA.
* Il valide le logiciel livré via un cahier de recette fonctionnelle.
* Il confie à l'IA la maintenance corrective et évolutive du logiciel.

Quelles sont les évolutions dans le détail ?
* L'ESN est soit évincée, soit marginalisée (ce n'est plus vraiment elle qui détient le savoir).
* L'ESN, si elle existe encore, aura besoin de beaucoup moins de développeurs.

Suis-je bien trop pessimiste ou naïf ? Je l'ignore, mais une amie développeuse junior qui se retrouve sur le marché du travail m'a appris récemment que le nombre d'emplois proposés aux juniors en Occitanie avait chuté de 80 % entre 2024 et 2025. Et si les seniors se croient à l'abri, ils se fourrent le doigt dans l'œil, car au rythme d'obsolescence des technologies en informatique, tout senior se retrouve junior au quotidien dans une partie de ses activités.

Les éditeurs de logiciels (libres ou non) peuvent aussi s'inquiéter si une IA arrive à régénérer un logiciel sur la seule base de ses spécifications et de son API.

Vous me direz que Chardet n'est qu'une modeste bibliothèque et que nous n'en sommes pas encore au point de pouvoir régénérer en quelques jours un logiciel bien plus complexe et c'est vrai. Mais rappelez-vous où nous en étions en mars 2023 (il y a seulement 3 ans), alors que tout le monde s'amusait encore des énormités générées par ChatGPT. Moi, je me demande où nous en serons dans 5 ans. Je sais que c'est l'une des questions que commencent à se poser les directions des ESN. Auront-elles encore besoin de 100 % de leurs effectifs actuels ou de seulement 20 %, voire 10 % ?

Le quelqu'un en question est Dan Blanchard, le mainteneur principal de la bibliothèque Chardet depuis 2011. Ce n'est donc pas du parasitisme. Il a juste décidé de faire table rase du passé comme nous le faisons au quotidien dans les projets (libres ou propriétaires), lorsque nous décidons de jeter un vieux code et de le remplacer par une nouvelle version plus performante ou plus moderne. Là, il l'a fait avec une IA et à une échelle jamais vue, sur un projet dont il assure bénévolement le développement depuis 15 ans. Cela lui donne une certaine légitimité, n'en déplaise à Mark Pilgrim, l'auteur originel de Chardet, qui a quitté le navire il y a 15 ans.

Ce choix relève certainement de l'automatisme et d'une croyance courante (GitHub assurerait une meilleure visibilité aux projets et faciliterait les contributions), mais il est vrai qu'à l'heure actuelle, j'aurais préféré lire que l'ANSSI privilégie la plateforme Codeberg.

Je parle de croyance concernant GitHub, car j'ai pu constater que dans les projets libres dans lesquels je suis ou j'ai été impliqué, le principal frein à la contribution n'était pas la création d'un compte sur une plateforme spécifique, mais :
1. La difficulté métier (disposer de compétences avancées dans le domaine adressé).
2. La difficulté technique (maitrise d'un langage exigeant tel que le C++ ou « exotique » tel que l'OCaml).

En outre, un site vitrine conçu de manière à être bien référencé et un nom de projet discriminant, ainsi qu'un peu de communication sur les médias adéquats, assurent une bien meilleure visibilité qu'un dépôt sur GitHub.

C'est de l'ordre du détail et il faut bien évidemment mettre à jour les applications, surtout lorsque ces mises à jour corrigent des failles de sécurité, mais la version de KeePassXC certifiée par l'ANSSI est la 2.7.9.

Cette certification est importante. Elle renforce la pertinence de l'utilisation de KeePassXC dans le cadre professionnel. À mon niveau, elle légitime la promotion de cet outil (et de son greffon KeePassXC-Browser, disponible pour Firefox, Chrome et Edge) que je fais depuis des années auprès de mes collègues.

Dans les deux cas – Gitea et Organic Maps – le problème n'est pas qu'un éditeur ou des contributeurs essaient de vendre des prestations autour du logiciel libre. Il existe une économie autour du logiciel libre et personne ne s'en plaint, bien au contraire.

Le problème est que, dans les deux cas, les termes de la collaboration, ce qui fait que des gens qui ne se connaissent pas décident de travailler ensemble à la création d'une œuvre collective, ont été copieusement foulés du pied par un petit nombre d'individus (2 ou 3 dans le cas d'Organic Maps, 1 dans le cas de Gitea). Ces types ont procédé à des actes déloyaux envers la communauté de ces projets (réservation de marque, transfert de propriété du nom de domaine, injection de blobs binaires dans l'application distribuée, etc.). Ils ont donc brisé la confiance et les communautés se rebiffent en forkant. Leur réaction est parfaitement légitime.

On ne s'engage dans un projet qu'après avoir pris connaissance des conditions d'engagement et des règles applicables. Si elles ne nous conviennent pas, on ne s'engage pas, si on se rend compte qu'elles sont délibérément foulées du pied, on quitte le projet. Cela vaut dans toutes les communautés.

Pour un projet libre, on souhaite connaitre les règles d'engagement :
- techniques (langage, outils, guide de contribution…),
- juridiques (licence, propriété des droits patrimoniaux, accords de contribution…),
- sociales (gouvernance, code de conduite…).

Il est du devoir des porteurs du projet, des mainteneurs, de faire preuve de transparence et de créer un climat de confiance en publiant ces différentes règles et en veillant à leur application (y compris par eux-mêmes, les passe-droits étant très mal vécus, comme on a pu le voir dans la communauté Rust). Si ces personnes ne le font pas, il ne faut pas qu'elles s'étonnent de ne pas agréger de communauté ou de voir leur communauté forker pour construire ailleurs un projet dont les règles de fonctionnement sont plus saines et acceptables par tous.

Bonjour à tou⋅te⋅s,

Sinon, si t'as pas d'imprimante, mais après cette dépêche tu réfléchis à t'en acheter une, tu dois te demander : j'achète quoi ?

Il y a aussi l'alternative du fablab, si on a la chance d'en avoir un près de chez soi.

J'ai pour ma part une utilisation occasionnelle des imprimantes 3D et des machines de découpe laser. Sans même parler du prix, acheter de tels équipements pour les utiliser quelques fois par an seulement ne serait pas responsable (je parle de mon cas, pas des fans d'impression 3D qui en font une utilisation quotidienne ou même hebdomadaire). En outre, ces machines sont encombrantes, alors que je vis dans un appartement.

Ce faisant, j'ai choisi de ne pas investir et d'adhérer à un fablab. Outre le matériel, j'y trouve des formations et une communauté, donc de l'expérience, du conseil et de l'intelligence collective, dont on profite en se rendant régulièrement sur place, et en concevant ses pièces sur site, au lieu de simplement y aller lorsqu'on a une impression à faire. Cela m'a permis de converger rapidement et d'éviter quelques erreurs lorsque j'ai réalisé mon dernier projet.

J'habite à Toulouse, où j'ai la chance d'avoir plusieurs fablabs « à proximité », dont le plus ancien de France, dont je suis membre depuis de longues années : Artilect.

Le fablab est réellement une alternative à considérer s'il en existe un près de chez vous. Certes, l'adhésion est payante, il faut se déplacer, ce n'est pas notre matériel, il n'est pas toujours disponible, il y a des horaires d'ouverture, c'est parfois bruyant et animé (ce qui n'est pas qu'un défaut), mais la mutualisation des équipements permet d'accéder à plus de matériel et cet environnement est stimulant.

Ne connaissant rien à Java et aux composants évoqués, ce que tu écris reste assez opaque pour moi. Il me faudrait un petit diagramme d'architecture.

Pour commencer, à ma connaissance, Maven est un outil de gestion des dépendances et d'automatisation du build, et d'aucune manière un composant lié à l'exécutable généré. Sa licence importe donc peu ici.

Ensuite, il me semble que JDBC est une simple abstraction, une interface définissant une API utilisée par les applications Java pour se connecter à des bases de données. Cette API est incluse dans la plateforme standard (sauf erreur de ma part, on la trouve donc aussi bien dans OracleJDK que dans OpenJDK). Mais cette interface ne permet rien en elle-même. Il faut ajouter un connecteur (« driver »), spécifique à chaque SGBDR. C'est donc la licence de ce connecteur qui importe. Quel SGBDR, et donc quel connecteur, utilises-tu ?

il faut étudier dépendance par dépendance, donc on peut mettre certains service en GPLv3, et laisser le reste en Apache v2.

Oui ou non. Cela dépend de la licence des différents composants, de leur assemblage et de leur mode d'interaction.

Je peux mettre en (L?)GPL v3 les service qui devraient être immuables chez les utilisateurs. Laisser le reste en Apache v2 pour ne rien imposer d'ennuyeux.

Je ne sais pas ce qu'est un service immuable.

Par contre, ce que je peux te dire, c'est que si la compilation de ton code aboutit à la génération de composants diffusés sous des licences différentes, tu as intérêt, pour le bien de tout le monde à commencer par le tien, à scinder le code desdits composants dans plusieurs dépôts et à les gérer séparément. Ton projet sera bien plus lisible sur le plan juridique.

J'oubliais, il est recommandé d'exclure du SBOM les composants qui ne sont utilisés qu'en phase de développement (JUnit par exemple) et ne sont pas liés aux versions de ton outil distribuées sous forme binaire.

Cf. un exemple de SBOM au format CycloneDX pour un composant Java :

https://github.com/CycloneDX/bom-examples/blob/master/SBOM/dropwizard-1.3.15/bom.xml

Bonjour,

Savoir si tu es à ton propre compte ou non ne suffit pas à déterminer si tu es en droit de décider de la licence de ton cadriciel, ni même de sa publication. Par exemple, si tu as développé ce cadriciel dans le cadre d'un contrat de prestation qui prévoit la cession des droits patrimoniaux à ton client (cas de figure assez fréquent), la décision appartient entièrement à ton client, et il n'a aucunement à te consulter ou à obtenir ton approbation pour cela.

Si ce n'est pas le cas (i.e. si tu as développé ce cadriciel de ta propre initiative, en le finançant sur fonds propres, ou si le contrat de prestation ne prévoit pas la cession des droits patrimoniaux), tu es en droit de décider de publier ton cadriciel sous licence libre.

La licence choisie doit être compatible avec celles des composants intégrés. Il faut donc commencer par établir leur liste. Selon les langages considérés et les outils disponibles, cette liste en profondeur – que l'on appelle un « Software Bill of Materials » (SBOM) ou « Software Supply Chain » – peut être établie de manière automatique ou non. De nos jours, il est de bon ton de publier ce SBOM au format CycloneDX. Publier le SBOM va même devenir une obligation en Europe avec la publication récente du « Cyber Resilience Act » (CRA).

Je ne l'ai jamais utilisé, mais je sais qu'un greffon Maven permet effectivement d'établir la liste exhaustive et en profondeur des composants intégrés. En effectuant une recherche rapide, je suis tombé sur l'article How to create SBOMs in Java with Maven and Gradle.

Si aucun des composants intégrés n'a de licence plus exigeante que la licence permissive Apache v2.0, tu peux décider de diffuser ton cadriciel sous cette licence ou sous une licence diffusive (faiblement, comme la licence GNU LGPL ou fortement, comme la licence GNU GPL). S'agissant d'un cadriciel, je déconseille le recours à une licence fortement diffusive qui dissuaderait beaucoup de personnes de l'utiliser (cette licence se diffusant alors à leur propre application), mais ce choix peut être une stratégie assumée.

La licence Apache v2.0 exige qu'une copie de la licence soit fournie à la racine du projet, dans un fichier nommé LICENSE(.txt), ainsi qu'un fichier NOTICE(.txt) contenant la liste des composants intégrés (liste de premier niveau, ceux que tu utilises explicitement et non ceux qui se trouvent intégrés en cascade, du fait des dépendances de dépendances).

Il est ensuite de bon ton de placer à la racine du projet un fichier README(.txt|.md|.rst) dans lequel tu auras inséré une mention de copyright et de licence (en renvoyant vers le fichier LICENSE(.txt).

Pour terminer, il est recommandé de placer une entête de copyright au début de chaque fichier dont le format le permet. Pour la licence Apache, cet entête peut être :

/*
 * Copyright (C) 2022-2024 John Doe
 *
 * This file is part of Taack-UI
 *
 *     https://taack-ui.org/
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

À ce stade, tu commences à avoir fait les choses plutôt bien. Reste éventuellement à choisir une licence différente et plus adaptée pour la documentation, les exemples et les ressources tierces. Pour plus d'informations à ce sujet, cf. mon article Projet libre : à chaque ressource sa licence.

Bonjour,

Étant (simple) adhérent à Artilect, je pense utile de fournir quelques informations supplémentaires :

• Artilect est un fablab situé au cœur de Toulouse, et même, d'un point de vue historique, le premier fablab de France.
• Le lien fourni dans le journal est issu d'une campagne de mailing. Les formations professionnelles dispensées par Artilect sont listées à l'adresse suivante, plus pérenne : https://artilect.fr/formation-professionnelle/.
• Artilect n'est donc pas un simple organisme de formation ; c'est un tiers-lieu où l'on rencontre des personnes aux profils très variés, qui n'hésitent pas à partager leur savoir-faire et leur expérience. J'adore y passer le samedi après-midi, même lorsque je n'ai pas d'atelier à animer ou que je n'ai pas prévu d'utiliser les moyens de fabrication d'Artilect.
• Vous l'aurez deviné, si vous êtes dans la région, je vous invite vivement à venir découvrir Artilect.

En tant qu'initiateur et animateur de l'OSPO de CS GROUP, j'adresse mes plus chaleureux remerciements aux membres du jury. Ce prix récompense 10 ans de travail, et même 15 ans si l'on considère la date de publication d'Orekit, premier logiciel libre publié par l'entreprise.

La bibliothèque Orekit est devenue une référence dans son domaine (la mécanique spatiale) et un véritable projet communautaire, utilisé aussi bien à des fins opérationnelles, que de recherche ou d'enseignement. Nous en sommes fiers. Nous avons investi 44 années.hommes à ce jour dans Orekit et ce projet reste notre plus belle réussite.

Nous avons cependant publié d'autres logiciels (certains sont tombés dans l'oubli, d'autres rencontrent un succès d'estime, tel EODAG) et versé de nombreuses contributions à des projets libres tiers (certaines étant récurrentes et s'inscrivant dans une logique l'implication durable, comme c'est le cas pour le noyau Linux).

À titre personnel, je suis heureux de travailler pour une entreprise qui ne se contente pas de puiser dans l'inestimable ressource qu'est le logiciel libre, mais y apporte de substantielles contributions.

Bonjour,

Pour aller plus loin que l'arrosage, il y a déjà FarmBot, projet libre tant sur le plan logiciel que matériel. Certes, je le reconnais, ce projet a de très nombreuses limites dès qu'on envisage une culture à grande échelle ou de faire pousser autre chose que des carottes ou des salades. Les pieds de tomates et de haricots doivent être un vrai casse-tête pour lui, tout comme les plantes coureuses telles que les courges.

Mais l'idée qu'un robot s'occupe (presque) de tout est séduisante quand on ne s'épanouit pas dans le jardinage, tout en appréciant les légumes issus du jardin et fraichement cueillis. :)

Bonjour,

Je fais moi aussi partie des gens qui impriment leur billet pour parer tout problème en cas de décharge impromptue de mon smartphone. Mais l'idée d'imprimer des encarts de publicité m'irrite au plus haut point. Je n'ai jamais cherché à extraire le QR-Code, mais j'ai trouvé une parade facile à mettre en œuvre pour tous les billets, qu'ils soient émis par la SNCF ou toute autre entité : j'édite le billet dans LibreOffice (qui sait lire les PDF), je sélectionne et je supprime toutes les images et autres éléments d'information sans intérêt. Puis j'imprime ce billet expurgé de tout superflu. Je conserve ainsi le QR-Code et toutes les informations importantes.

La version est française est également très bien pour les francophones pas encore polyglottes.

Je n'en doute pas, mais à ma connaissance, le livre n'a pas encore été édité en français, contrairement à la version anglaise qui trône désormais dans le coin de ma bibliothèque où je regroupe tous les ouvrages libres (bandes dessinées, romans, essais et manuels) que j'ai achetés ici et là.

En outre, si Benoit indique que le texte a été traduit, je n'ai pas trouvé en ligne de version PDF incluant les images et le texte.

J’ai découvert le livre lors d’un séminaire interne des référents Open Source/logiciel libre

Je fais partie des heureux gagnants d'un exemplaire en anglais. Je n'avais jamais eu vent moi non plus de ce livre auparavant.

Même s'il s'agit avant tout d'un conte moderne à l'attention des enfants, je l'ai beaucoup apprécié. L'histoire est sympa, le vilain n'est pas très méchant au fond, il semble même « très cool » au début puisqu'il fait le bonheur des gens en leur fournissant moult machines plus géniales les unes que les autres. Mais cela lui donne les moyens de régenter leur vie et, au détour d'une contrariété, il cède à cette facilité. S'en suit la découverte des problèmes induits par le contrôle centralisé de la technologie, de l'importance de la loi qui peut interdire ou autoriser, de la connaissance émancipatrice et, bien sûr, du rôle central que joue le logiciel dans notre société.

Ces sujets a priori un peu ésotériques pour les enfants sont présentés dans ce livre d'une manière imagée et accessible. Je vous recommande chaudement ce conte si un livre en anglais ou en allemand ne rebute pas vous ou vos enfants.

J'ai réalisé mon boitier à Artilect, grâce aux machines mises à disposition par ce fablab et avec les précieux conseils des bénévoles et permanents. Même à supposer que nous ayons les moyens d'acquérir une machine à découpe laser, réaliser nos projets dans un tiers lieu permet de mutualiser les moyens et donc, de maximiser leur utilisation. En outre, cet environnement s'avère stimulant. Chez vous, vous n'aurez jamais l'opportunité d'échanger et de profiter de l'intelligence collective qui imprègne un tel lieu.

Artilect traverse une mauvaise passe financière et a besoin de notre soutien. Voici la campagne que vient de lancer l'équipe sur helloasso :

Artilect a besoin de vous

Mais maintenant, j'ai pu acquérir sur LE site de vente en ligne un NAS WD de 8To (4To utile) pour 378 euros.

Je n'ai qu'une objection à cette approche : le système d'exploitation n'est pas libre. ;)

D'ailleurs, au boulot, j'ai introduit les NAS Synology il y a une douzaine d'années et la qualité de ces produits (WebOS ergonomique et socle logiciel maintenu pendant au moins 7 ans) a fait que les NAS Synology ont progressivement évincé tous les autres. Mais à titre personnel, je voulais un NAS doté d'un OS libre. J'ai opté pour TrueNAS Core pour monter en compétence, mais vu mes besoins immédiats, j'aurais pu me contenter d'une distribution OpenMediaVault, voire Debian.

Dans le cas présent, pour le même prix qu'un NAS Synology DS220+ doté des mêmes disques de stockage des données, j'ai un NAS doté d'un Celeron de 11ème génération à 4 cœurs (au lieu d'un Celeron à 2 cœurs), de 16 Go de RAM extensibles (au lieu de 2 Go non extensibles), d'un disque système NVMe de 500 Go (128, voire 64 Go auraient été largement suffisants, mais le modèle 500 Go de la même gamme était meilleur marché) et de deux interfaces réseau à 2,5 Gbit/s (au lieu d'une à 1 Gbit/s).

Le plug & play n'est pas utile dans mon cas. En cas de défaillance d'un disque, je peux largement prendre le temps d'arrêter mon NAS, de le démonter et de changer le disque.

Et pour la découpe laser, je suis effectivement passé par l'un des fablabs toulousains, nommé Artilect, dont je suis membre. Plus de détails dans mes deux articles :
- 2023-06-18 – Boitier en découpe laser pour NAS DIY
- 2023-05-10 – NAS DIY à base de carte Odroid-H3

J'ai posé à question aux membres du fablab Artilect, ils m'ont dit que le polycarbonate jaunissait lorsqu'on le découpait au laser (information que j'ai aussi trouvée sur le net, où il est indiqué que le problème empire avec l'épaisseur de la plaque).

Il est indiqué dans la documentation du projet TrueNAS (section Error Correcting Code Memory) :

Error-correcting code or ECC RAM detects and corrects in-memory bit errors as they occur. If errors are severe enough to be uncorrectable, ECC memory causes the system to hang (become unresponsive) rather than continue with errored bits. For ZFS and TrueNAS, this behavior virtually eliminates any chances that RAM errors pass to the drives to cause corruption of the ZFS pools or file errors.

To summarize the lengthy, Internet-wide debate on whether to use error-correcting code (ECC) system memory with OpenZFS and TrueNAS:

Most users strongly recommend ECC RAM as another data integrity defense.
However:
* Some CPUs or motherboards support ECC RAM but not all
* Many TrueNAS systems operate every day without ECC RAM
* RAM of any type or grade can fail and cause data loss
* RAM failures usually occur in the first three months, so test all RAM before deployment.

La recommandation n'a rien de spécifique à ZFS, il n'est pas indiqué « si vous n'utilisez pas de RAM ECC, n'utilisez pas ZFS ». Il est simplement dit que la RAM ECC évite la propagation d'une erreur en RAM au système de stockage, puisqu'elle engendre le gel instantané du système. Cela est vrai quel que soit le système de stockage considéré.

Les cartes supportant la mémoire ECC sont bien plus couteuses, tout comme la RAM ECC elle-même. La configuration requise aurait donc eu un tout autre cout (sans même parler de l'encombrement). In fine, le jeu n'en vaut pas la chandelle vu que ce NAS ne va être que l'un des supports de mes données et sauvegardes.

Merci ! :)

Je donne des informations supplémentaires dans l'article que j'ai publié sur mon blog et que j'ai oublié de pointer dans le journal :

https://www.palabritudes.net/2023/06/18/boitier-decoupe-laser-nas-diy.html

Une machine de découpe laser permet de découper, mais aussi de graver, tout dépend de la puissance du laser et de la focalisation du faisceau. Les traits qui apparaissent en rouge sur le plan et ont une épaisseur de 0,001 mm désignent des traits de découpe, ceux qui apparaissent en noir et sont plus épais désignent des zones à graver.

La pièce est découpée en 23 minutes sur la machine que j'ai utilisée, mais ce temps dépend de la puissance du laser (j'ai utilisé une machine 35 Watts, mais Artilect en dispose d'une à 120 Watts, qui était en maintenance ces dernières semaines). En outre, la gravure du QR-Code prend plusieurs minutes à elle seule (ce QR-Code fournit l'url du projet sur ma forge, ce faisant, une personne tombant sur un exemplaire du NAS peut découvrir les sources du projet).

Le temps de travail est assez difficile à estimer. J'ai passé 6 après-midi à Artilect, mais c'est un lieu d'échange où l'on bénéficie des conseils de membres plus expérimentés et où on a par contre vite fait de se disperser. À part cela, j'ai passé une poignée de soirées à modéliser, à faire des recherches pour étudier les différentes solutions d'assemblage qui s'offraient à moi et à rechercher les pièces qu'il me fallait. Au total, quelques dizaines d'heures d'essai et, surtout, 3 prototypes qui m'ont permis de valider ou d'invalider des pistes, et de découvrir lors du montage, que j'avais raté un ou deux trucs. :)

Du coup, je me renseignerai lorsque je retournerai à Artilect.