On recommande KeepassXC dans nos ateliers d’éducation populaire. Je viens de voir passer qu’ils acceptent les PR générée entièrement ou pour partie par LLM :
Je résume ce que je comprends des usages LLM :
Résumé des modifications et code review pour suggérer des soucis dans une PR
Création de code dans des PR qui résolvent des soucis simples et concis, par exemple ajouter des tests.
Autant pour des PR générées par des outils d’IA gérés par les mainteneurs que pour des PR de contributeur.ices
Dans tous les cas toutes les PR sont revues par un des 5 mainteneurs du projet
At KeePassXC, we use AI for two main purposes:
As an additional pair of “eyes” in code reviews.
In this function, AI summarises the changes (the least helpful part) and points out implementation errors a human reviewer may have missed. AI reviews don’t replace maintainer code review, nor do they relieve maintainers from their due diligence. AI code reviews complement our existing CI pipelines that perform unit tests, memory checks, and static code analysis (CodeQL). As such, they are a net benefit and make KeePassXC strictly safer. Some examples of AI reviews in action: example 1, example 2.
For creating pull requests that solve simple and focused issues, add boilerplate code and test cases.
Unfortunately, some people got the impression that KeePassXC was now being vibe coded. This is wrong. We do not vibe code, and no unreviewed AI code makes it into the code base. Full stop. We have used Copilot agent to draft pull requests, which are then subsequently tweaked in follow-up commits, and reviewed by a maintainer, openly for anyone to see, with the same scrutiny as any other submission. Good pull requests are merged (example), bad pull requests are rejected (example).
All this is only part of the development process. There are no AI features inside KeePassXC and there never will be!
Si c’est vraiment le cas, c’est un gros engagement je trouve.
Ça c’est très courant sur de nombreux projets, notamment parce que les fonctionnalités sont soit activées par défaut, soit très facile à activer.
Ce doc à le mérite de faire le bilan des pratiques du projet (ou du moins les objectifs que l’équipe se fixe).
Personnellement, si les pratiques de relecture sont bien celles présentées, je ne pense pas que ça aura un impact négatif sur la sécurité de la solution (ce sera peut être même l’inverse).
Par contre, ça participe à normaliser l’usage d’outils si complexe qu’on ne peut pas les fabriquer nous même. Et, il y a l’aberration écologique de ces technos en général.
Qu’entends-tu par outils si complexe ? Perso, je ne comprends rien à l’utilisation de generative AI, mais si on me cause mathématique linéaire ou non-linéaire et machine learning, deap learning, ça va, je comprends.
Du coup, ça amène à définir plus précisément «on ne peut pas les fabriquer nous même.» (si cela peut être un critère discriminant)
Je pense que c’est un résumé simple d’une partie du consensus général contre les LLM (consommation d’énergie et de matériel énormes, infrastructure de vol de données qui pourrit nos serveurs, etc).
Si on joue avec les mots, on peut trouver moult exemples de trucs qu’on peut pas fabriquer nous-mêmes sans que ce soit grave ^^
Si je suis contre les LLM et les projets vibe codés, là il s’agit d’outils utilisés par les dévs sur leurs pratiques personnelles, et pas sur les parties sensibles, et avec une grosse conscience des limitations, ça ne me dérange pas trop au fond.
C’est un peu comme voir des dévs utiliser Visual Studio Code pour développer : l’outil est pourri éthiquement, mais c’est un choix personnel de l’environnement de dév de la personne, et moi j’aimerais pas trop qu’on vienne m’embêter à me dire que mon environnement de dév n’est pas « éthique ». Mais c’est peut-être parce que j’utilise du propriétaire déjà (Sublime Text) pour coder. Principalement car c’est ce que je sais utiliser, et que je préfère faire du code que de passer du temps à réapprendre un autre outil.
Perso ça n’atteint pas ma confiance envers KeepassXC, mais il faut bien sûr rester vigilant⋅e⋅s sur ce genre d’utilisation ce qui est permis par leur modèle qui privilégie la transparence et permet de savoir ce qui vient de l’assistant et ce qui vient de l’humain.
Je trouve que ça pose aussi la question de combien de temps il faudra aux mainteneureuses pour observer que l’IA fait très bien son bouleau (parce que potentiellement elle le fait très bien) et qu’iels finissent, naturellement, a avoir une confiance aveugle en celle-ci ? C’est le risque avec tout ces outils j’ai l’impression c’est que les introduire c’est aussi risquer de se laisser convaincre…
Est ce qu’il faut imposer à ce genre d’outil une sorte de barrière de principe, quitte a se priver de certains avantage pour éviter de finir dépendant ? Le risque est aussi que si on interdit simplement, que chacun.e en fasse a sa guise sans en parler aux autres?
Je me demande aussi, est-ce qu’il y a une politique commune des CHATONS sur l’usage de l’IA dans les projets open source/libres ?
Grosse question !
On n’a jamais cherché à obtenir de consensus là-dessus.
À ma connaissance, certains CHATONS ont un usage limité de genAI.
Et on héberge des applis qui veulent pousser des LLM un peu partout (Nextcloud par exemple), mais c’est encore possible de désactiver tout ça.
Comme le dit ppom j’entends par là surtout les moyens industriel nécessaires (pas tellement la technique). Ça freine forcément la contrib si il faut avoir un accès à des infras de dingue pour récolter de la données et faire de l’apprentissage énergivore.
Mais ppom a raison aussi de dire qu’il y a plein d’autres choses dans ce cas. De nombreux objets typiquement (à commencer par nos pc), ceci dit les objets une fois transmis t’appartiennent, ce n’est pas vraiment le cas d’une IA générative en mode SaaS… Bref, on se retrouve avec un soucis équivalent à celui des index de moteurs de recherche.
C’est vraiment une question purement éthique. Si ce n’est pas utilisé pour vibe-coder, effectivement ça semble acceptable dans ce cadre. Mais :
les LLM restent toujours écocides et socialement discutable et tout ça essentiellement pour économiser du temps.
comme dit, accepter sont utilisation pour ça, ça déplace la fenêtre d’Overton quand à son acceptation. Et donc pour l’instant le cadre est restraint, mais une fois que son utilisation sera accepté rien ne dit que les limites du cadres ne seront pas étendus.
Et puis je crois que c’est pas juste une question de fenêtre d’Overton, de ce qui est acceptable, c’est une question de dépendance à la technique, pour moi le risque c’est aussi qu’on ne sache plus faire sans.
industriel = des datacenter entiers sont nécessaires pour fabriquer les réseaux de neuronnes qui vont bien pour faire ces IAgen de même pour récolter les données nécessaires. Donc pas accessible financièrement pour des petits groupes. => C’est ce point qui fait que pour le moment l’IA gen n’est pas à notre portée.
technique = les algos et méthodo pour arriver aux résultats (qui sont à notre portée de compréhension, je pense)
Je ne sais pas répondre à la question de @GautGaut . Sa question a le mérite de poser les choses. Je ne joue pas sur les mots. Je préfère utiliser des mots adéquats quand je le peux.
Copilot est dans les tuyaux depuis quasi 10 ans. Le rachat par m$ n’a fait qu’accélérer les choses. Du point de vue de KeepassXC → Zéro capex et Zéro opex parce que c’est le dev le produit. C’est la définition du capitalisme de plateforme. (Cf Corinne Vercher Chaptal)