#Nextquick : libre et open source ne sont pas synonymes de sécurité

Sans être antinomique non plus

#Nextquick : libre et open source ne sont pas synonymes de sécurité

Voici le premier article du nouveau format lancé par Next. On attaque avec une « croyance populaire » sur la cybersécurité et l’open source. Rendre le code accessible est une bonne chose, mais ce n’est pas suffisant sans vérifications supplémentaires.

Le 03 octobre 2025 à 18h00

Commentaires (27)

votre avatar
L'avantage de sécurité au niveau de l'open-source/libre (et en fait, source available en général), c'est que lorsqu'une faille est détectée, elle est souvent plus rapidement corrigée, et on peut regarder la correction qui a été apportée.

Il s'agit d'une revue de code, certes, que peu feront en pratique (c'est une certitude), mais le correctif pour heartblead par exemple, a été revu par plusieurs experts du domaine tant cette partie a été mise en avant. Ce n'est pas comme si il fallait faire l'audit d'un projet entier (qui revient à rechercher une aiguille dans une botte de fois), mais plutôt de vérifier la taille de l'aiguille une fois qu'on l'a trouvée ;)
votre avatar
On en avais parlé récemment sur Discord, je remet ici un lien qui a fait beaucoup parler et est plus spécifiquement centré sur Linux (plus sécurisé que Windows/macOS, vous dites ?) :

https://wonderfall.space/linux-securite/
votre avatar
yes, je m'en souviens. Dans un contexte justement de la fin de Windows 10 :yes:
votre avatar
Le seul code source sécurisé est celui qui n'a pas encore été écrit 😅
votre avatar
Ou qui n'est pas exécuté.

Comme quand on disait à l'époque que le meilleur moyen de sécuriser un serveur, c'était de le débrancher et le mettre dans un coffre.
votre avatar
De même, quand mes parents me faisaient des leçons de morale après avoir fait une « connerie* » , et avec des phrases du genre :
« et pourtant on t’avait prévenu de bien faire attention »,

ma réponse :
« c’est sûr, quand on ne fait rien, on ne risque pas de se tromper non plus »

(* par exemple un peu de peinture en moins sur carrosserie de la familiale en revenant le Dimanche matin @ 6h du mat et d'autres aussi...:D)
votre avatar
Au delà du choix du nom de la rubrique, il faudrait surtout une fonctionnalité pour afficher ce qu'il signifie, c'est moins rebutant pour tous les nouveaux que de voir d'obscurs termes un peu partout (LIDD, Nextquic...).

Surtout qu'ils vont être nombreux à débarquer via LPL :D
votre avatar
En fait, à titre perso, j'ai jamais trop ressenti ou entendu la croyance du "libre / open source = sécurité". Elle tourne plutôt autour de l'écosystème Linux où bon nombre d'idiots pensent encore aujourd'hui ne pas être la cible de malwares. Remarque, l'autre mythe du "si c'est open source on peut lire les failles dans le code" est encore régulièrement répété.

Dans le domaine du logiciel, souvent ce qui "rassure" en entreprise avec les produits d'éditeurs c'est le fait que l'usage repose derrière un contrat avec des obligations et des garanties.

En principe.

Evidemment, un éditeur ne peut pas promettre le "zéro faille" dans le contrat, mais il peut s'engager sur un délais de correction des problèmes du produit. Là où le libre / open source communautaire (car attention, le libre / open source est aussi commercial) se fera au bon vouloir de la réactivité des mainteneurs.

Donc j'avoue qu'en ce qui concerne mon expérience, l'argument en faveur du libre / open source est plus lié à sa gratuité qu'à sa supposée sécurité.
votre avatar
Pas nécessairement. Il est tout à fait possible de payer des développeurs pour assurer le service/garantie d'un produit open-source / libre derrière. Des milliers de webmasters le font pour prestashop par exemple, pour les pros.
C'est même probablement mieux qu'un logiciel propriétaire pour une entreprise, qui conserve le code source des applications métiers et n'est pas à la merci d'un unique prestataire, et peut même maintenir son propre fork adapté à des besoins spécifiques.
Et ce n'est qu'un exemple parmi d'autres.
votre avatar
Mes expériences en matière de dev interne en entreprise oscillent entre l'horreur et la catastrophe. Que ce soit en matière de délais de production et de qualité.

Les entreprises qui veulent dev en interne ne se rendent jamais compte des prérequis nécessaires que ce soit en nombre de personnes et en financier (sauf lorsqu'elles ont un coeur de métier qui s'approche de la Tech). Ou alors vont appliquer les orga à la mode où chaque produit va avoir son PM/PO/SDM/Tech lead et potentiellement 2 devs (voire des "devops") parce que le budget est déjà cramé par le premier troupeau. On se retrouve avec des "feature team" qui passent leur temps à pousser de la feature et non de la maintenance pour justifier leur existence et montrer leur "vélocité".
Et derrière, ça fini avec un produit troué de partout non entretenu. Et comme les 3/4 de l'équipe qui l'a dev est externe, plus personne ne sait comment il marche.

Sans oublier que qui dit dev interne dit méthodo pour la production du logiciel avec tous les contrôles de sécurité et de qualité qui accompagnent le delivery avec donc les compétences et les outils adaptés.

La dette technique en entreprise est toujours très mal gérée, surtout lorsqu'il s'agit de demander un budget pour traiter des exigences non fonctionnelles. Déjà que les besoins métier se font arbitrer...
votre avatar
Je ne suis pas sur qu'un éditeur puisse s'engager sur un délai de correction des problèmes.

Il peut fournir un patch qui "fait un truc" , et surtout il peu être redevable de pénalités financières... si tu es plus gros que lui.
Et quelque part c'est ça que cherche les grosses boites dans les autres grosses boites : La capacité financière à payer quand le problème arrivera. Pas le fait qu'il n'y ait pas de problèmes. Du coup le problème effectif et sa correction devient secondaire.
Microsoft je trouve est un bon exemple: Tu fais quoi contre eux lorsque ça marche pas (Ce qui m'arrive au moins 5/6 fois par semaine entre teams / sharepoint / azure /...) ? Bah rien, parce que tu n'es rien , même si tu es une multinationale.
votre avatar
Quelqu´un a des news de Grosquic?
votre avatar
votre avatar
(Je reprenais juste le titre de la rubrique: Nextquic.

Nextquic - Grosquic. Même nombre de lettres, même terminaison.)
votre avatar
Ah ok, j'avais pas capté 😅
votre avatar
C’EST QUI LE GROS ? JE SUIS UN PEU ENVELOPPÉ ET J’AI DE GROS OS :o :roule2:
votre avatar
après avoir été viré comme un malpropre par Nestlé pour cause d'embonpoint, au profit d'un lointain neveu plus mince et socialement acceptable, il me semble qu'il s'est retiré de la vie publique
votre avatar
Le petit neveu qui a réussi à faire bouffer ses crottes aux enfants, accessoirement.
votre avatar
Un peu HS, mais c'est quoi le principe du format ? J'ai pas vu un grosse différence 😅

Edit : j'avais pas lu le quoi de neuf a la rédac 🙂 je comprends mieux.
votre avatar
Intéressant.
Parce contre c'est dommage que la différence entre libre et open source soit évoquée mais pas explicitée.

Sinon je propose RTFA (pour Article) car on pourra renvoyer quelq'un ici s'il pose une question déjà répondue :transpi:
votre avatar
On reste focus on a dit, la différence libre et open source pourra être traiter évidemment, mais dans un autre article, dossier, etc. Si je m’éparpille on revient au point de départ :prof:
votre avatar
Voir ce nom de news en se réveillant, rien de mieux pour apprécier un petit déjeuner :D
votre avatar
C’est vrai que 13h17 du matin c’est l’heure du petit déj :pastaper:
votre avatar
Nextquic c'est bien je trouve comme nom de rubrique.
Et comme on le dit souvent : la sécurité est un processus pas un produit.
votre avatar
S'il y a un domaine où l'IA peut se révéler utile pour les devs, à mon avis c'est celui-là. Les revues automatiques pour déceler les failles peuvent être utiles, si elles sont bien faites. (je suis assez réfractaire à l'IA en général, sans pour autant tout rejeter en bloc)
Daniel Stenberg, le dev de curl qui a maintes fois écrit contre l'usage abusif de l'IA, admet cela après qu'un chercheur ait révélé des bugs/failles ("truly awesome findings").

Problème évident: si on peut le faire en "défensif", les hackers peuvent le faire en "offensif". Et pour le coup c'est un avantage au closed source.
votre avatar
En tout cas, ces derniers jours, l'I.A., l'opensource et la sécurité , ça fait des vagues:

https://www.theregister.com/2025/10/01/critical_red_hat_openshift_ai_bug/

(bon à priori les clowns qui ont conçu l'intégration des outils AI dans openshift ont fait comme de nombreuses startups: ils n'ont pas réfléchis à ce qu'ils faisaient avec le rbac)
votre avatar
"Et pour le coup c'est un avantage au closed source."

Pas du tout... l'I.A. est très performante pour lire du code machine directement et lui redonner du sens, il y a beaucoup d'effort mis en ce moment pour faire une génération d'outils forensics/décompilation basés sur l'I.A. et les résultats sont très encourageants ( sauf si on aime pas la transparence )

#Nextquick : libre et open source ne sont pas synonymes de sécurité

  • Pouvoir vérifier le code est bien différent de l’avoir vraiment fait

  • Un logiciel fermé n’est pas synonyme ou antonyme de sécurisé

  • Ayez confiance

Fermer