L’intelligence artificielle ne tue pas l’open source. En revanche, elle est en train de bousculer en profondeur les regles implicites sur lesquelles l’ecosysteme reposait depuis des annees : contribution volontaire, maintenance collective, responsabilite technique partagee et economie fragile de projets tenus a bout de bras par peu de personnes.
La vraie question n’est donc pas de savoir si l’IA va faire disparaitre le logiciel libre. La vraie question est plus brutale : que devient l’open source quand produire du code devient facile, mais que le comprendre, le corriger et l’assumer reste un travail humain, lent et exigeant ?
L’IA ne casse pas l’open source, elle deforme ses incitations
Selon Stormy Peters, figure historique de l’open source et responsable de la strategie open source chez AWS, l’IA ne detruit pas le logiciel libre. En revanche, elle attaque deja ses equilibres sociaux et economiques. Et elle le fait plus vite que beaucoup de projets, de fondations et d’entreprises ne sont capables de s’adapter.
Autrement dit, le probleme n’est pas seulement technique. Il touche directement la maniere dont les contributions sont produites, evaluees, maintenues et financees.
Le premier choc : l’arrivee massive du bruit
Le premier effet visible de l’IA dans l’open source, c’est le bruit. Les maintainers voient de plus en plus arriver des rapports de bugs, des patches et des pull requests generes ou fortement assistes par IA, mais insuffisamment verifies.
Sur le papier, cela peut sembler positif. Plus de contributions, donc potentiellement plus d’ameliorations. En realite, beaucoup de ces propositions sont mediocres, mal comprises par leurs auteurs, et coutent un temps considerable a ceux qui doivent les examiner.
C’est l’un des points les plus durs souleves par Stormy Peters : les gens ne gardent pas pour eux le code genere rapidement par IA. Ils le soumettent. Et souvent, ils le soumettent sans etre capables de le defendre, de l’expliquer ou de le maintenir ensuite.
Le code devient plus simple a produire, mais plus cher a relire
Le fantasme dominant autour de l’IA est connu : elle ferait gagner du temps a tout le monde. Mais cette promesse se heurte a une realite bien moins flatteuse pour les projets open source.
Quand un contributeur genere une modification en quelques secondes, il transfere souvent le vrai cout sur le maintainer. Ce dernier doit comprendre un code qu’il n’a pas ecrit, verifier qu’il n’introduit pas de regression, juger sa coherence avec le reste du projet, puis parfois le reecrire presque entierement.
Le gain apparent d’un cote devient une dette immediate de l’autre. L’IA accelere la production de matiere brute, mais elle n’automatise ni le jugement, ni la responsabilite, ni la maintenance. Et c’est justement la que se concentre la valeur des projets serieux.
Les maintainers paient deja l’addition
L’exemple de cURL illustre parfaitement cette derive. Ce projet open source, present dans des milliards d’appareils, disposait d’un programme de recompense pour les vulnerabilites. Pendant plusieurs annees, cela a permis de faire remonter de vrais problemes de securite et de les corriger utilement.
Puis l’IA est arrivee dans la boucle. En tres peu de temps, les maintainers ont vu apparaitre une avalanche de signalements qui n’apportaient aucune faille exploitable, mais monopolisaient du temps humain. Le systeme de prime, pense pour recompenser un vrai travail d’analyse, s’est retrouve pollue par des soumissions rapides, peu fiables et mal filtrees.
Le probleme n’est donc pas abstrait. Il touche deja la securite, la priorisation et la capacite de reaction des projets critiques.
Le mythe de la productivite automatique
Autre idee tres repandue : l’IA rendrait les developpeurs plus rapides. C’est parfois vrai sur certaines taches simples, mais cela devient beaucoup moins evident des qu’on parle de mainteneurs experimentes ou de codebase complexe.
Stormy Peters a rappele des travaux montrant que, pour des developpeurs confirmes, l’usage de l’IA peut au contraire ralentir. Pourquoi ? Parce qu’il faut relire, corriger, ajuster et verifier ce code presque bon, mais pas suffisamment bon pour etre integre en confiance.
Le point le plus inquietant reste ailleurs : le code genere par IA tend a presenter davantage de problemes. Si la quantite augmente, mais que la fiabilite baisse, alors la charge globale de l’ecosysteme s’alourdit.
Le plaisir de creer se deplace, la fatigue de maintenir reste
L’IA change aussi la repartition psychologique du travail. Elle donne a des contributeurs moins experimentes le plaisir immediat de produire quelque chose vite. En revanche, elle laisse aux maintainers la partie la moins gratifiante : relire, simplifier, reparer, harmoniser et absorber les erreurs.
Or l’open source repose justement sur un equilibre fragile entre enthousiasme, competence et responsabilite. Si l’on industrialise la soumission de code faible et que l’on reserve la difficulte aux quelques personnes deja sursollicitees, on use encore plus vite le coeur du systeme.
La gouvernance tente de rattraper le retard
Face a cette situation, de plus en plus de projets mettent a jour leurs regles. Certains interdisent purement et simplement l’usage de l’IA pour coder. D’autres l’acceptent, mais a condition qu’elle soit declaree et utilisee de maniere responsable. Entre les deux, beaucoup improvisent encore.
Le probleme, c’est que les pratiques reelles sont souvent opaques. Meme lorsqu’un projet demande la divulgation de l’usage d’une IA, une minorite de contributeurs l’indique clairement. Cela complique l’analyse des risques, la tracabilite et la conformite sur le plan des licences ou de la qualite.
L’IA pourrait aussi changer les projets que l’on cree
Un autre effet commence a apparaitre : si une IA peut generer rapidement des petits utilitaires ou des micro-fonctions, certains developpeurs peuvent se dire qu’il n’est plus utile de publier de petites bibliotheques open source pour cela. A premiere vue, cela peut sembler benefique, car cela reduit le nombre de dependances dans la chaine logicielle.
Mais cette evolution coupe aussi une voie d’entree historique dans l’open source. Pendant longtemps, beaucoup de developpeurs se sont fait connaitre en publiant un outil modeste, simple, utile, puis en construisant leur place dans l’ecosysteme a partir de la. Si tout devient jetable ou genere a la demande, une partie de cette dynamique pourrait disparaitre.
Ce que les projets doivent faire maintenant
Le message de Stormy Peters est clair : il faut agir tout de suite, pas dans cinq ans. Plusieurs leviers concrets existent deja.
- mieux documenter les projets, car les IA apprennent d’abord a partir de la documentation
- donner des consignes explicites aux nouveaux contributeurs qui utilisent l’IA
- demander l’attribution du code assiste par IA
- refuser toute soumission que l’auteur ne comprend pas vraiment
- reexaminer les dependances et limiter les chaines inutiles
- continuer a financer les projets open source critiques
Ce dernier point est central. Si les entreprises continuent a consommer massivement de l’open source sans renforcer leur contribution en amont, l’IA ne fera qu’aggraver une faiblesse deja ancienne : trop peu de mainteneurs pour trop d’infrastructure critique.
Alors, l’IA est-elle en train de tuer l’open source ?
Non. Mais elle est clairement en train d’en changer les conditions de survie. Elle introduit du bruit, brouille les responsabilites, fragilise la maintenance et accelere des tensions que l’ecosysteme connaissait deja.
Le danger n’est pas la disparition brutale du logiciel libre. Le danger, c’est une degradation silencieuse de sa qualite, de ses incitations et de sa soutenabilite. L’open source ne mourra pas d’un coup. En revanche, il peut s’epuiser si l’on transforme les maintainers en service de nettoyage permanent pour code genere trop vite.
La periode actuelle est courte, tendue et decisive. Si les projets, les fondations et les entreprises mettent des regles claires en place maintenant, l’IA peut encore devenir un outil utile. Sinon, elle risque surtout d’augmenter la charge de ceux qui tiennent deja l’infrastructure du monde numerique avec des moyens insuffisants.