Je comprends l'idée derrière la comparaison, mais elle ne me semble pas tenir : contribuer avec une IA n'est pas une agression et les mainteneurs ne sont pas des victimes à qui l'on demanderait de s'adapter.
Il y a pourtant un point juste : la charge pèse sur eux.
Le mainteneur de curl a dû dénoncer publiquement l'afflux de faux rapports de sécurité générés par IA. Un mainteneur noyé sous ce genre de contributions a besoin de règles claires pour refuser sans y passer ses soirées.
Mais l'inverse existe aussi : un projet complexe, utile à beaucoup, porté par une seule personne qui finit par s'épuiser (xz-utils) ; on ne compte plus les projets abandonnés.
Pour ces mainteneurs-là, un contributeur sérieux qui s'aide d'une IA, teste, documente et assume ce qu'il propose, peut être un vrai soulagement.
C'est à eux de décider, ça ne devrait pas être une règle de principe. On peut leur donner des outils sans leur demander de s'adapter. Ça leur permet de choisir et de cadrer leur projet, y compris de dire non.
Je comprends la distinction, et elle me paraît juste : le Libre porte un projet d'émancipation, pas seulement une méthode de développement.
Dans ce cadre, refuser l'IA au nom de ses conséquences est une position cohérente et, personnellement, j'adhère à beaucoup d'argument anti-IA. Un projet qui fait ce choix est d'ailleurs parfaitement légitime à l'inscrire dans ses règles ; c'est même ce que je défendais : que chaque projet puisse définir son cadre.
Ce qui me gêne, c'est d'en faire une règle de principe.
Si le critère est la destruction des conditions de vie, il s'applique aussi à une bonne partie de ce que nous utilisons déjà : matériel, réseaux, centres de données, extraction minière, … Je ne dis pas ça pour relativiser l'IA, mais parce que je ne sais pas où placer la limite de façon juste. Où la places-tu ?
À titre personnel, je vis avec cette contradiction : l'outil m'aide, et je doute qu'il soit soutenable. Je préfère la garder ouverte plutôt que de la trancher trop vite, dans un sens comme dans l'autre.
Pour autant, je ne prétends pas avoir raison. C'est justement pour ça que la discussion m'intéresse.
J'avais voulu répondre à @Ploum. Je me permets de mettre ma réponse ici (non envoyée). Je ne le vise pas particulièrement mais son texte m'a fait m'interroger face à mon utilisation personnelle de l'IA et du code.
Je crois qu'on mélange parfois deux questions : l'outil utilisé pour produire une contribution et les conséquences de cet outil.
Pour un projet Open Source, le mainteneur peut fixer ses règles : qualité, tests, sécurité, documentation, maintenabilité, revue, etc. Si une contribution respecte ces règles et fonctionne, pourquoi son origine devrait-elle suffire à la disqualifier ?
Une IA peut produire du mauvais code, mais aussi du très bon. Très peu de développeurs maîtrisent par ailleurs toutes les couches techniques qu'ils utilisent quotidiennement : processeur, compilateur, système d’exploitation, matériel, … Nous acceptons depuis longtemps cette réalité.
Pourquoi faudrait-il faire exception pour l'IA ? La question me semble donc moins être "qui a écrit le code ?" que "ce code répond-il aux exigences du projet ?".
Cela n'empêche évidemment pas de questionner l'IA elle-même. Son coût environnemental et social est réel, mais l'informatique consomme, exploite et transforme déjà énormément : ressources minières, énergie, composants, infrastructures, déchets, conditions sociales de production, …
L'IA ne devrait ni être exonérée de cette réflexion, ni devenir le bouc émissaire qui permet d'oublier ces impacts.
Plutôt que d'interdire l'IA par principe, il me semblerait plus utile de donner aux mainteneurs des outils pour gérer ces nouvelles contributions : modèles de gouvernance, règles de contribution, exigences de transparence, tests, documentation et revue.
Gérer un projet Open Source est déjà un travail en soi ; autant aider ceux qui le font à définir un cadre dans lequel chacun peut contribuer correctement.
À titre personnel, l'IA m'aide à contribuer mais je reste sceptique sur sa pérennité sous sa forme actuelle au regard des ressources qu'elle nécessite. Pour autant, cela ne me semble pas une raison pour fermer la porte à ceux qui peuvent apporter une bonne contribution avec cet outil.
Quant à l'Art du code et à la perte de certaines compétences, qui sont de vraies questions, elles me semblent surtout poser celle de l'évolution d'un métier et des habitudes : ce que nous devons continuer à savoir faire, ce que nous pouvons déléguer et ce que nous devons apprendre à contrôler autrement. C'est un autre sujet légitime.
Lovasoa, juste bravo, déjà. J'aime ton approche du web comme outil (affichage de texte, médias et formulaires) et non comme marché (énième framework).
SQLPage est extrêmement simple (un seul fichier), il permet de faire du web rapidement et de manière durable en se concentrant sur le contenu.
Comme dit plus haut, le foisonnement des outils proposés est une excellente chose, l'existence de SQLPage y a toute sa place parce qu'il semble remplir une case vide (celle de la réelle simplicité) parmi la multitude d'outils de développement.
Pour autant, on ne peut pas (encore ?) téléverser de fichiers. ;)
[^] # Re: Je suis un Amish!
Posté par gwado . En réponse à la dépêche Debian, IA, vibe coding & rsync : la croisée des chemins ?. Évalué à 0 (+1/-1).
Je comprends l'idée derrière la comparaison, mais elle ne me semble pas tenir : contribuer avec une IA n'est pas une agression et les mainteneurs ne sont pas des victimes à qui l'on demanderait de s'adapter.
Il y a pourtant un point juste : la charge pèse sur eux.
Le mainteneur de curl a dû dénoncer publiquement l'afflux de faux rapports de sécurité générés par IA. Un mainteneur noyé sous ce genre de contributions a besoin de règles claires pour refuser sans y passer ses soirées.
Mais l'inverse existe aussi : un projet complexe, utile à beaucoup, porté par une seule personne qui finit par s'épuiser (xz-utils) ; on ne compte plus les projets abandonnés.
Pour ces mainteneurs-là, un contributeur sérieux qui s'aide d'une IA, teste, documente et assume ce qu'il propose, peut être un vrai soulagement.
C'est à eux de décider, ça ne devrait pas être une règle de principe. On peut leur donner des outils sans leur demander de s'adapter. Ça leur permet de choisir et de cadrer leur projet, y compris de dire non.
[^] # Re: Je suis un Amish!
Posté par gwado . En réponse à la dépêche Debian, IA, vibe coding & rsync : la croisée des chemins ?. Évalué à 1 (+1/-0).
Je comprends la distinction, et elle me paraît juste : le Libre porte un projet d'émancipation, pas seulement une méthode de développement.
Dans ce cadre, refuser l'IA au nom de ses conséquences est une position cohérente et, personnellement, j'adhère à beaucoup d'argument anti-IA. Un projet qui fait ce choix est d'ailleurs parfaitement légitime à l'inscrire dans ses règles ; c'est même ce que je défendais : que chaque projet puisse définir son cadre.
Ce qui me gêne, c'est d'en faire une règle de principe.
Si le critère est la destruction des conditions de vie, il s'applique aussi à une bonne partie de ce que nous utilisons déjà : matériel, réseaux, centres de données, extraction minière, … Je ne dis pas ça pour relativiser l'IA, mais parce que je ne sais pas où placer la limite de façon juste. Où la places-tu ?
À titre personnel, je vis avec cette contradiction : l'outil m'aide, et je doute qu'il soit soutenable. Je préfère la garder ouverte plutôt que de la trancher trop vite, dans un sens comme dans l'autre.
Pour autant, je ne prétends pas avoir raison. C'est justement pour ça que la discussion m'intéresse.
[^] # Re: Je suis un Amish!
Posté par gwado . En réponse à la dépêche Debian, IA, vibe coding & rsync : la croisée des chemins ?. Évalué à 2 (+3/-1).
J'avais voulu répondre à @Ploum. Je me permets de mettre ma réponse ici (non envoyée). Je ne le vise pas particulièrement mais son texte m'a fait m'interroger face à mon utilisation personnelle de l'IA et du code.
Je crois qu'on mélange parfois deux questions : l'outil utilisé pour produire une contribution et les conséquences de cet outil.
Pour un projet Open Source, le mainteneur peut fixer ses règles : qualité, tests, sécurité, documentation, maintenabilité, revue, etc. Si une contribution respecte ces règles et fonctionne, pourquoi son origine devrait-elle suffire à la disqualifier ?
Une IA peut produire du mauvais code, mais aussi du très bon. Très peu de développeurs maîtrisent par ailleurs toutes les couches techniques qu'ils utilisent quotidiennement : processeur, compilateur, système d’exploitation, matériel, … Nous acceptons depuis longtemps cette réalité.
Pourquoi faudrait-il faire exception pour l'IA ? La question me semble donc moins être "qui a écrit le code ?" que "ce code répond-il aux exigences du projet ?".
Cela n'empêche évidemment pas de questionner l'IA elle-même. Son coût environnemental et social est réel, mais l'informatique consomme, exploite et transforme déjà énormément : ressources minières, énergie, composants, infrastructures, déchets, conditions sociales de production, …
L'IA ne devrait ni être exonérée de cette réflexion, ni devenir le bouc émissaire qui permet d'oublier ces impacts.
Plutôt que d'interdire l'IA par principe, il me semblerait plus utile de donner aux mainteneurs des outils pour gérer ces nouvelles contributions : modèles de gouvernance, règles de contribution, exigences de transparence, tests, documentation et revue.
Gérer un projet Open Source est déjà un travail en soi ; autant aider ceux qui le font à définir un cadre dans lequel chacun peut contribuer correctement.
À titre personnel, l'IA m'aide à contribuer mais je reste sceptique sur sa pérennité sous sa forme actuelle au regard des ressources qu'elle nécessite. Pour autant, cela ne me semble pas une raison pour fermer la porte à ceux qui peuvent apporter une bonne contribution avec cet outil.
Quant à l'Art du code et à la perte de certaines compétences, qui sont de vraies questions, elles me semblent surtout poser celle de l'évolution d'un métier et des habitudes : ce que nous devons continuer à savoir faire, ce que nous pouvons déléguer et ce que nous devons apprendre à contrôler autrement. C'est un autre sujet légitime.
# Bel outil
Posté par gwado . En réponse à la dépêche Écrire une appli web en une journée avec SQLPage. Évalué à 3. Dernière modification le 09 juillet 2023 à 23:05.
Bonjour,
Lovasoa, juste bravo, déjà. J'aime ton approche du web comme outil (affichage de texte, médias et formulaires) et non comme marché (énième framework).
SQLPage est extrêmement simple (un seul fichier), il permet de faire du web rapidement et de manière durable en se concentrant sur le contenu.
Comme dit plus haut, le foisonnement des outils proposés est une excellente chose, l'existence de SQLPage y a toute sa place parce qu'il semble remplir une case vide (celle de la réelle simplicité) parmi la multitude d'outils de développement.
Pour autant, on ne peut pas (encore ?) téléverser de fichiers. ;)