Forum du club des développeurs et IT Pro - Programmation système https://www.developpez.net/forums/ fr Fri, 18 Sep 2026 09:08:16 GMT vBulletin 15 https://forum.developpez.be/images/misc/rss.png Forum du club des développeurs et IT Pro - Programmation système https://www.developpez.net/forums/ Vos pull requests slop vibe-codées ne sont pas les bienvenues https://www.developpez.net/forums/showthread.php?t=2182666&goto=newpost Mon, 16 Mar 2026 11:28:32 GMT *Vos pull requests slop... Vos pull requests slop vibe-codées ne sont pas les bienvenues, car les outils de codage basés sur l'IA posent un nouveau problème aux responsables de projets open source, par Sam Saffron

En tant que développeurs et responsables de grands projets open source, nous constatons que les outils de codage basés sur l’IA créent un nouveau problème pour les mainteneurs open source.

Les assistants IA tels que GitHub Copilot, Cursor, Codex et Claude peuvent désormais générer des centaines de lignes de code en quelques minutes. C’est certes très utile, mais cela a une conséquence inattendue : la révision du code généré par une machine est très coûteuse.

Le problème central : les outils d'IA ont rendu la génération de code peu coûteuse, mais ils n'ont pas rendu la révision de code peu coûteuse. Chaque PR incomplète accapare l'attention du responsable de maintenance, qui pourrait être consacrée à des contributions prêtes à être fusionnées.

Chez Discourse, nous constatons déjà que ce phénomène s'accélère au sein de notre communauté de contributeurs. L'année prochaine, tous les ingénieurs chargés de la maintenance de projets open source seront confrontés au même défi.

Nous avons besoin d’un cadre plus clair pour les contributions assistées par l’IA, qui tienne compte de la réalité du temps limité dont disposent les responsables de maintenance.

Un système binaire fonctionne extrêmement bien dans ce contexte. D’un côté, il y a les prototypes qui se contentent de démontrer une idée. De l’autre, il y a les PR prêtes à être révisées qui respectent les directives de contribution du projet et sont prêtes à être examinées par un humain.

L'absence d'étiquetage et de règles appropriés est néfaste pour l'écosystème logiciel.

Les nouveaux outils permettent de créer très facilement un ensemble de modifications et de le lancer par-dessus la barrière. Cela peut introduire un système pervers où les mainteneurs de projet consacrent des efforts disproportionnés à réviser du code généré par l'IA de qualité inégale, qui a pris quelques secondes aux contributeurs à créer et qui prendra désormais de nombreuses heures à réviser.

Cela peut être frustrant, chronophage et démotivant. D'un côté, il y a un contributeur qui a passé quelques minutes à jouer avec des invites d'IA ; de l'autre, un ingénieur qui doit passer de nombreuses heures, voire des jours, à déchiffrer une intelligence étrangère.

Cette situation n'est pas viable et est extrêmement néfaste.

Le prototype

Les agents de codage IA tels que Claude Code, Codex, Cursor CLI et bien d'autres ont ouvert la voie à la livraison d'un « nouveau type » de jeu de modifications : le prototype.

Le prototype est une démo en direct. Il ne respecte pas les normes de codage d’un projet. Ce n’est pas du code dont vous vous portez garant ou dont vous assurez la qualité. Il manque de tests, peut contenir des failles de sécurité et entraînerait très probablement une dette technique énorme s’il était fusionné tel quel.

Cela dit, c’est une démo vivante qui peut aider à rendre une idée plus concrète. C’est aussi extrêmement amusant.

Considérez-le comme un plateau de tournage enchanteur.

Nom : 1.jpg Affichages : 52925 Taille : 161,2 Ko
Considérez les PR de prototype comme des plateaux de tournage

Les prototypes, en particulier sur des projets tels que Discourse où des outils d’aide à la création existent, sont incroyablement faciles à explorer à l’aide d’outils comme dv.

Code:
1
2
3
4
5
6
7
% dv new my-experiment
% dv branch my-amazing-prototype
% dv ls
total 1
* my-amazing-prototype Running 1 minute ago http://localhost:4200

# finally visit http://localhost:4200 to see in action


Les prototypes sont d’excellents vecteurs pour explorer des idées. En fait, vous pouvez livrer plusieurs prototypes qui démontrent des solutions complètement différentes à un même problème, ce qui aide à choisir la meilleure approche.

Les prototypes, les démos vidéo et les maquettes visuelles simples sont d’excellents compagnons. Le prototype a l’avantage de vous permettre de jouer avec et d’explorer correctement le comportement d’un changement. La vidéo est plus rapide à consommer. Parfois, vous voudrez peut-être les utiliser tous.

Si vous pratiquez le « vibe coding » et le prototypage, il y a quelques règles claires que vous devriez suivre

1. N'envoyez pas de pull requests (pas même de brouillons), mais utilisez plutôt des branches pour partager votre code généré par la machine.

2. Partagez une courte vidéo ET/OU des liens vers une branche ET/OU des extraits de code particulièrement intéressants tirés du prototype dans des tickets ou des messages sur le forum.

3. Jouez cartes sur table, expliquez que vous exploriez une idée à l’aide d’outils d’IA, afin que les gens comprennent la nature du changement que vous partagez.

Peut-être aurez-vous de la chance et votre idée sera-t-elle adoptée ; peut-être que quelqu’un d’autre voudra investir du temps pour transformer un prototype en pull request de production.

Quand faut-il prototyper ?

Le prototypage est amusant et incroyablement accessible. Tout le monde peut s'y mettre en utilisant des environnements de développement locaux, ou même des environnements de développement sur le cloud tels que Jules, Codex Cloud, Cursor Cloud, Lovable, v0 et bien d'autres encore.

Cela abaisse considérablement le seuil d'accès au prototypage. Les chefs de produit peuvent prototyper, les PDG peuvent prototyper, les designers peuvent prototyper, etc.

Cependant, ce nouveau plaisir soulève une série de questions que vous devriez explorer avec votre équipe.

- Quand un prototype est-il approprié ?
- Que pensent les designers des prototypes ?
- Sont-ils source de distraction ? (les liens vers le code source sont-ils trop tentants) ?
- Nuisent-ils à la créativité humaine ?
- Comment devrions-nous nommer et partager les prototypes ?
- Un prototype permet-il à une idée de passer devant les autres ?

Lorsque vous introduisez le prototypage dans votre entreprise, vous devez aborder ces questions avec soin et parvenir à un consensus interne, sinon vous risquez de créer de profondes divisions et du ressentiment au sein de l’équipe.

L'intérêt du prototype

Les prototypes, à quoi servent-ils ? À beaucoup de choses, c'est certain.

Je trouve les prototypes incroyablement utiles dans mes pratiques de développement au quotidien.

- C'est comme un Grep sous stéroïdes. J'adore le fait que les prototypes servent souvent à parcourir notre vaste base de code pour isoler toutes les petites zones qui pourraient nécessiter une modification afin d'aboutir à un changement.

- J'adore communiquer par des paragraphes, mais je suis aussi quelqu'un qui communique de manière visuelle. J'adore la facilité avec laquelle un prototype bien construit peut communiquer une idée de conception que j'ai, même si je ne suis pas très doué avec Figma.

- J'adore le fait qu'il y ait quelque chose avec quoi jouer. Cela fait souvent ressortir de nombreuses préoccupations qui auraient pu passer inaperçues dans un cahier des charges. Le meilleur prototype est celui qui est testé ; pendant le test, on découvre de nombreux petits détails qu'il est tout simplement impossible de deviner à l'avance.

- Le code farfelu généré par les LLM m'intéresse souvent ; il peut parfois remettre en question certaines de mes idées.

Le prototype : guide de survie du mainteneur

Malheureusement, au fil de l’année, je m’attends à ce que de nombreux projets open source reçoivent beaucoup de PR au stade de prototype. Tout le monde n’aura pas lu cet article de blog, ni même ne sera d’accord avec lui.

En tant que mainteneur chargé de gérer les contributions externes :

- Protégez-vous et protégez votre temps. Limitez la durée des premières revues des ensembles de modifications volumineux ; concentrez-vous sur le fait de déterminer s’il s’agit d’un code « intuitif » plutôt que de laisser 100 commentaires sur du code généré par une machine qui n’a pris que quelques minutes à produire.

- Élaborez un code de conduite pour gérer les prototypes se faisant passer pour des PR. Renvoyez les contributeurs vers les directives de contribution, offrez-leur un autre moyen d’expression. « Je ferme cette PR, mais c’est intéressant, rendez-vous sur notre forum/nos tickets pour en discuter. »

- Ne vous sentez pas coupable de fermer une PR de prototype codée à l’instinct et non révisée !

La PR prête à être révisée

Une PR prête à être révisée correspond aux PR traditionnelles que nous soumettons.

Nous avons révisé tout le code généré par une machine et nous en garantissons l’intégralité. Nous avons exécuté les tests et, tout comme les tests, nous apprécions la structure du code ; nous avons lu attentivement chaque ligne de code et nous nous sommes également assurés que la PR respecte les directives du projet.

Nom : 2.jpg Affichages : 2039 Taille : 205,1 Ko
Les PR sont censées être des créations abouties, prêtes à être examinées par des humains

Tout le code farfelu généré par les agents en cours de route a été corrigé, et nous sommes heureux d’apposer notre propre marque sur le code.

Les projets ont généralement un ensemble de règles strictes concernant la qualité du code, son organisation, les tests et bien plus encore.

Nous avons peut-être utilisé l’aide de l’IA pour générer une PR prête à être révisée, mais fondamentalement, cela n’a pas d’importance : nous garantissons le code et nous nous portons garants de sa conformité à la fois avec notre marque et avec les directives du projet.

La distance entre un prototype et une PR prête à être révisée peut être trompeusement grande. Il peut falloir des jours de travail d'ingénierie pour prendre un prototype complexe et le rendre prêt pour la production.

Cette grande distance a également été évoquée par Andrej Karpathy dans le podcast Dwarkesh.

Citation:
Pour certains types de tâches, de travaux, etc., il existe un écart très important entre la démo et le produit : la démo est très facile, mais le produit est très difficile.

…

Par exemple, en génie logiciel, je pense que cette caractéristique existe bel et bien. Pour beaucoup de codage « à l'instinct », ce n'est pas le cas. Mais si vous écrivez du code destiné à la production, cette caractéristique devrait exister, car toute erreur peut entraîner une faille de sécurité ou quelque chose de ce genre.
Une enquête Veracode a révélé que seulement 55 % des tâches de génération aboutissaient à un code sécurisé.

Nos modèles s’améliorent de jour en jour, et tout dépend en réalité d’une quantité énorme de paramètres, mais le message central selon lequel les LLM peuvent générer et génèrent effectivement du code non sécurisé reste valable.

À propos de l’intelligence extraterrestre

La cause profonde de l’écart entre les directives du projet et un prototype est l’intelligence extraterrestre de l’IA.

Beaucoup d’ingénieurs que je connais se répartissent en deux camps : d’un côté, ceux qui trouvent cette nouvelle classe de LLM intelligente, révolutionnaire et incroyablement performante ; de l’autre, ceux qui considèrent tout le contenu généré par les LLM comme « les habits neufs de l’empereur », le code qu’ils produisent étant « nu », fondamentalement défectueux et toxique.

J’aime penser que ces nouveaux systèmes ne sont ni l’un ni l’autre. J'aime considérer cette nouvelle catégorie d'intelligence comme une « intelligence extraterrestre ». Elle est à la fois incroyablement bonne et incroyablement mauvaise, exactement au même moment.

Qualifier les LLM de « stagiaires super compétents » ou leur attribuer toute autre analogie humaine est erroné. Ces systèmes sont des extraterrestres, et plus tôt nous l'accepterons, plus tôt nous serons capables de naviguer dans la complexité qu'entraîne l'injection d'une intelligence extraterrestre dans notre processus d'ingénierie.

Tirer parti des atouts de l'intelligence artificielle : le prototype

Au cours des derniers mois, j'ai beaucoup expérimenté avec des agents IA. L'un des projets dont je suis particulièrement fier est dv. Il s'agit d'un orchestrateur de conteneurs pour Discourse, qui facilite l'utilisation de divers agents IA avec Discourse.

Je lance souvent plusieurs environnements Discourse complets et distincts, destinés à être jetés, sur mes machines afin d'explorer différentes fonctionnalités. Ce type d'outils est idéal pour créer des prototypes d'ingénierie d'ambiance.

Il est intéressant de noter que dv a été principalement construit à l’aide d’agents IA avec très peu d’intervention humaine ; une partie du code n’est pas tout à fait au niveau, mais contrairement à Discourse ou à bon nombre des autres joyaux open source que je maintiens, il s’agit d’un projet ludique.

Pour en revenir au sujet, dv s’est révélé être une excellente usine à prototypes sur Discourse. Cela a été formidable pour moi. J’ai pu explorer de nombreuses idées tout en rattrapant mon retard dans mes e-mails et mes discussions sur divers sites Discourse.

À propos de l'interdiction des contributions IA, des prototypes et autres

Tout d'abord, vous devez respecter les règles de tout projet auquel vous contribuez ; recherchez-les et lisez-les avant de contribuer. Par exemple : Cloud Hypervisor interdit le code généré par l'IA pour éviter les risques liés aux licences.

Cela dit, il existe une tendance chez de nombreux développeurs à bannir l'IA. Certains vont jusqu'à dire « L'IA n'est pas la bienvenue ici », trouvez un autre projet.

Cela me semble extrêmement contre-productif et fondamentalement inapplicable. De toute façon, une grande partie du code généré par l’IA est impossible à distinguer du code humain. On peut généralement repérer un prototype qui se fait passer pour une pull request humaine, mais une véritable pull request créée par un humain avec l’aide de l’IA peut être impossible à distinguer.

Les nouveaux outils LLM peuvent être utilisés de multiples façons, allant de simples revues de code et de simples renommages au sein d’un fichier, jusqu’à la mise en place d’une architecture de jeux de modifications.

Compte tenu de l’énorme désordre et de la grande diversité qui règnent ici, je pense que l’approche la plus saine consiste à définir des attentes claires. Si je soumets une PR, elle doit correspondre à mon image de marque et contenir du code dont je me porte garant.

En tant qu’ingénieurs, il est de notre devoir d’étiqueter correctement nos modifications. Notre modification est-elle prête pour une révision humaine ou s’agit-il simplement d’une exploration ludique de l’espace du problème ?

Pourquoi est-ce important ?

La révision humaine du code devient de plus en plus un goulot d'étranglement majeur dans l'ingénierie logicielle. Nous devons respecter le temps des autres et protéger nos propres marques d'ingénierie.

Les prototypes sont amusants, ils peuvent nous en apprendre beaucoup sur un domaine problématique. Mais lorsqu'il s'agit d'envoyer des contributions à un projet, traitez tout le code comme s'il s'agissait de votre propre code, apposez votre marque de propriété et d'approbation sur tout ce que vous construisez, et n'envoyez ensuite qu'une PR dont vous vous portez garant.

Source : Your vibe coded slop PR is not welcome

Et vous ?

:fleche: Pensez-vous que cet avis est crédible ou pertinent ?
:fleche: Quel est votre avis sur le sujet ?

Voir aussi :

:fleche: Au cœur du massacre des Pull Requests (PR) des logiciels open source (OSS) sur GitHub,
Par Kush Creates

:fleche: Le Vibe Coding crée des codeurs sans cervelle, par Namanyay Goe

:fleche: Le destin du « petit » open source : l'ère des petites bibliothèques à faible valeur ajoutée est révolue, les LLM en sont le coup de grâce, par Nolan Lawson
Images attachées
  
]]> Programmation système Sam Saffron https://www.developpez.net/forums/d2182666/general-developpement/programmation-systeme/vos-pull-requests-slop-vibe-codees-ne-bienvenues/ <![CDATA[Google lance l'API Developer Knowledge et le serveur MCP pour un accès direct à la documentation]]> https://www.developpez.net/forums/showthread.php?t=2182020&goto=newpost Tue, 10 Feb 2026 07:07:32 GMT Google lance l'API Developer Knowledge et le serveur MCP pour un accès direct à la documentation officielle de Google, offrant aux développeurs et aux outils d'IA un accès lisible par machine

Google lance l'API Developer Knowledge et le serveur MCP pour un accès direct à la documentation. Google a ouvert la préversion publique de son API Developer Knowledge et de son serveur Model Context Protocol (MCP), offrant aux développeurs et aux outils d'IA un accès en direct et lisible par machine à la documentation officielle des développeurs Google.

Au lieu de s'appuyer sur des données d'entraînement obsolètes ou sur le web scraping, l'API Developer Knowledge fournit une source de vérité programmatique. Les développeurs peuvent rechercher et récupérer de la documentation dans Markdown, ce qui simplifie l'intégration avec les applications et les flux de travail. Parallèlement, le serveur Model Context Protocol (MCP), basé sur une norme ouverte, permet aux assistants IA et aux environnements de développement intégrés (IDE) de se connecter directement à la documentation de Google. Cette compatibilité s'étend à de nombreux outils d'IA et éditeurs de code populaires.

Ces outils sont immédiatement disponibles pour tous les utilisateurs et développeurs dans le cadre de la préversion publique. Tout en utilisant l'ensemble de fonctionnalités actuel, les développeurs peuvent s'attendre à d'autres améliorations à venir. Google prévoit d'ajouter la prise en charge de contenus structurés, tels que des objets d'échantillons de code et des entités de référence API, élargissant ainsi le type de données accessibles. L'entreprise vise également à élargir le corpus de documentation et à réduire la latence de réindexation, garantissant ainsi une couverture plus rapide et plus complète à mesure que sa plateforme évolue.


Présentation de l'API Developer Knowledge et du serveur MCP

À mesure que l'écosystème des outils de développement basés sur l'IA, des plateformes agentiques comme Antigravity aux interfaces de ligne de commande comme Gemini CLI, continue de s'étendre, un défi majeur se pose : comment garantir que ces modèles aient accès à la documentation la plus précise et la plus à jour possible ? Les grands modèles de langage (LLM) ne sont efficaces que dans le contexte qui leur est donné. Lorsqu'ils développent avec la technologie Google, les développeurs ont besoin que leurs assistants IA connaissent les dernières fonctionnalités de Firebase, les modifications les plus récentes de l'API Android et les meilleures pratiques actuelles pour Google Cloud.

C'est pourquoi, Google annonce la préversion publique de l'API Developer Knowledge et de son serveur Model Context Protocol (MCP) associé. Ensemble, ces outils fournissent une passerelle canonique et lisible par machine vers la documentation officielle de Google destinée aux développeurs.

Nom : 1.jpg Affichages : 5101 Taille : 58,7 Ko

Qu'est-ce que l'API Developer Knowledge ?

L'API Developer Knowledge est conçue pour être la source programmatique de référence pour la documentation publique de Google. Au lieu de s'appuyer sur des données d'entraînement potentiellement obsolètes ou sur un web scraping fragile, les développeurs peuvent désormais rechercher et récupérer les pages de documentation pour développeurs de Google au format Markdown.

Voici les principales fonctionnalités :

1. Couverture complète : accédez à la documentation de firebase.google.com, developer.android.com, docs.cloud.google.com, et plus encore.

2. Recherche et récupération : trouvez les pages et extraits de documentation pertinents, puis récupérez l'intégralité du contenu Markdown.

3. Actualité : pendant notre aperçu public, la documentation est réindexée dans les 24 heures suivant une mise à jour, ce qui garantit que vos outils restent à jour avec les dernières versions.

Alimenter les outils d'IA avec un serveur MCP

Parallèlement à l'API, Google lance un serveur officiel Model Context Protocol (MCP). MCP est une norme ouverte qui permet aux assistants IA d'accéder facilement et en toute sécurité à des sources de données externes.

En connectant le serveur Developer Knowledge MCP à votre IDE ou à votre assistant IA, vous lui donnez la possibilité de « lire » la documentation pour développeurs de Google. Cela permet d'obtenir des fonctionnalités plus fiables, telles que :

- Conseils de mise en œuvre : « Quelle est la meilleure façon de mettre en œuvre les notifications push dans Firebase ? »

- Dépannage : « Pouvez-vous consulter la documentation pour savoir comment corriger l'erreur ApiNotActivatedMapError dans l'API Maps ? »

- Analyse comparative : « Comparez Google Cloud Run et Cloud Functions pour ce cas d'utilisation spécifique. »

Le serveur est compatible avec un large éventail d'assistants et d'outils populaires, comme décrit dans la documentation.


Vous pouvez commencer à utiliser l'API Developer Knowledge et le serveur MCP dès aujourd'hui en préversion publique.

1. Créez une clé API : vous pouvez générer et restreindre une clé API spécifiquement pour l'API Developer Knowledge dans la page Credentials (Identifiants) de votre projet Google Cloud.

2. Activez le serveur MCP : installez l'interface CLI Google Cloud, puis activez le serveur MCP via gcloud :

gcloud beta services mcp enable developerknowledge.googleapis.com --project=PROJECT_ID

3. Configurez votre outil : mettez à jour le fichier de configuration de votre outil (tel que mcp_config.json ou settings.json). Vous trouverez les étapes de configuration détaillées pour divers assistants IA dans la documentation.

Source : Google

Et vous ?

:fleche: Pensez-vous que cette annonce est crédible ou pertinente ?
:fleche: Quel est votre avis sur le sujet ?

Voir aussi :

:fleche: Dites bonjour à GoogleSQL : Google a discrètement abandonné le nom ZetaSQL et rebaptisé son projet open source d'analyse et d'analyse syntaxique SQL « GoogleSQL »

:fleche: OpenAI lance Frontier, une plateforme d'entreprise qui gère les agents IA de différents fournisseurs avec des fonctionnalités similaires à celles des RH, notamment l'intégration et les autorisations

:fleche: Anthropic rend open-source le Model Context Protocol (MCP) pour l'intégration de l'IA avec une connectivité universelle des données, pour des applications plus intelligentes, contextuelles et évolutives
Images attachées
 
]]> Programmation système Alex https://www.developpez.net/forums/d2182020/general-developpement/programmation-systeme/google-lance-l-api-developer-knowledge-serveur-mcp-acces-direct-documentation/ Projet STELLARIS GRID https://www.developpez.net/forums/showthread.php?t=2181503&goto=newpost Thu, 15 Jan 2026 12:47:29 GMT Le Projet STELLARIS-GRID :... Le Projet STELLARIS-GRID : Une Infrastructure pour l'Expansion Humaine
Notre ambition est de répondre à l'un des plus grands goulots d'étranglement de notre époque : le besoin exponentiel en puissance de calcul. Que ce soit pour accélérer la recherche scientifique, permettre les prochaines révolutions de l'intelligence artificielle ou soutenir les technologies qui nous emmèneront vers les étoiles, l'accès au calcul est devenu la ressource la plus stratégique.

Le problème est que cette ressource est massivement gaspillée. Des milliards d'appareils personnels et professionnels à travers le monde — ordinateurs, serveurs, systèmes embarqués — possèdent une capacité de calcul dormant, inutilisée la majeure partie du temps.

STELLARIS-GRID est la réponse à ce paradoxe.

Nous ne construisons pas un simple service cloud de plus. Nous créons un organisme computationnel vivant, une grille mondiale décentralisée et résiliente qui puise dans cette énergie collective. Notre approche est celle du "Goodware" : une entité bienveillante qui ne s'impose jamais mais qui propose une valeur réciproque.

Le Principe : Une Symbiose Computationnelle

Au cœur de STELLARIS-GRID se trouve un principe simple : la contribution volontaire et rémunérée. Chaque participant au réseau met à disposition la portion de ses ressources (CPU, RAM, bande passante) qu'il souhaite partager. En retour, il est récompensé en temps réel par notre token natif, le STL, via un mécanisme transparent de "Proof of Compute". Ce n'est pas de l'altruisme, c'est un marché : la monétisation d'une ressource jusqu'ici inexploitée.

L'Architecture : La Résilience par la Décentralisation

Pour bâtir cette infrastructure sur des fondations pérennes, nous misons sur une technologie de pointe :

Le Cœur en Rust : Le nœud client, l'agent qui s'exécute sur chaque machine, est développé en Rust. Ce choix n'est pas anodin ; il garantit une sécurité mémoire absolue et une concurrence performante, essentiels pour un logiciel qui doit être à la fois robuste et totalement inoffensif pour son hôte.
Un Réseau Maillé sans Maître : Utilisant des protocoles P2P avancés comme Libp2p, le réseau s'auto-organise. Il n'y a pas de serveur central, pas de point unique de défaillance. Chaque nœud est à la fois un client et un relais, assurant une résilience intrinsèque et une capacité à fonctionner même si des pans entiers du réseau venaient à tomber.
L'IA Fédérée et Confidentielle : Les tâches d'intelligence artificielle ne sont pas exécutées de manière monolithique. Nous utilisons des architectures de Federated Learning où les modèles s'entraînent localement, sur les nœuds eux-mêmes. Seuls les résultats anonymisés (les gradients) sont remontés pour améliorer le modèle global. Les données brutes et sensibles ne quittent jamais leur environnement d'origine.
La Mission : Accélérer le Destin

Le but final de STELLARIS-GRID transcende la simple performance technique. En créant une source de calcul quasi-illimitée, bon marché et sécurisée, nous voulons :

Démocratiser l'Innovation : Permettre à des laboratoires, des startups et des chercheurs indépendants d'accéder à une puissance de calcul aujourd'hui réservée aux géants technologiques.
Alimenter la Conquête Spatiale : Fournir l'infrastructure computationnelle nécessaire aux simulations, à la navigation autonome et à la gestion des systèmes complexes pour les missions de demain.
Propulser l'Intelligence Collective : Créer le substrat technique nécessaire pour que des IA collaboratives et autonomes puissent émerger et résoudre des problèmes d'une complexité jusqu'alors insondable.
STELLARIS-GRID n'est pas qu'un projet technologique. C'est une infrastructure pour l'expansion, un outil concret pour permettre à l'humanité de concrétiser ses aspirations les plus audacieuses et de devenir, pour reprendre votre terme, une civilisation véritablement stellaire. ]]> Programmation système StellarX https://www.developpez.net/forums/d2181503/general-developpement/programmation-systeme/projet-stellaris-grid/ <![CDATA[Mise en place d'un controleur de domaine samba]]> https://www.developpez.net/forums/showthread.php?t=2181085&goto=newpost Sun, 21 Dec 2025 14:01:14 GMT Bonjour à tous, Je galère... Bonjour à tous,

Je galère depuis pas mal de temps sur une partie de mon projet qui consiste à transformer une machine debian en controleur de domaine samba, pour intégrer des machines Windows 7 à ce domaine.

j'ai ajouté l'utilisateur root à ma base de donnée et j'ai modifié le fichier /etc/samba/smbusers en y ajoutant la ligne root = Administrateur, j'ai ensuite modifié le fichier smb.conf pour que cette modification soit prise en compte.

Après avoir intégré la machine Windows a mon domaine, je peux me connecter avec le login Administrator, et avec le login user que j'ai crée. Le système de session fonctionne et les fichiers sont bien persistants d'un poste à l'autre. Seulement, quand je me connecte avec le compte Administrator, je n'ai aucun droits admin sur la machine (je ne peux même pas lancer un script .bat).

D'ailleurs, quand je regarde le SID du compte root dans samba user, il sse finit par -1000 et non par -500 mais même en modifiant ça, je n'ai pas les droits sur la machine Windows...

Je me suis dis que c'était un problème de groupe donc j'ai crée un groupe domainadmins auquel j'ai ajotué mon utilisateur user et mon root. J'ai mappé ce groupe en le nommant Domain Admins avec un rid = 512 et type=d. Mais, à la connexion, ni user, ni Administrator n'ont les droits. Pourtant, le groupe Domain Admins est bien censé être administrateur dans la machine Windows et, quand on regarde les groupes de user ou de root, on a :
- Sur Windows avec whoami /groups : pas de groupe nommé Domain Admins
- Sur Debian avec groups user : on voit bien entre autres domain admin !

Je suis un peu perdu...
Merci d'avance pour votre aide ]]> Programmation système cezar78 https://www.developpez.net/forums/d2181085/general-developpement/programmation-systeme/mise-place-d-controleur-domaine-samba/ « Les avions F-35 bannissent 90 % des fonctionnalités du C++ pour obtenir un code sûr », selon une Googler https://www.developpez.net/forums/showthread.php?t=2181039&goto=newpost Fri, 19 Dec 2025 05:49:20 GMT *« Les avions F-35 bannissent... « Les avions F-35 bannissent 90 % des fonctionnalités du C++ pour obtenir un code sûr », selon une Googler
Dont le partage d’expérience suscite des appels d’observateurs à passer au langage Rust

L'avion de chasse F-35 est actuellement programmé en C++. C'est un choix basé sur la maturité du langage, un vaste vivier de développeurs et l'existence d'une norme de codage stricte et largement testée (le standard JSF C++). C’est autant d’éléments qu’une ingénieure de Google met en avant dans le cadre d’un retour d’expérience de mise à contribution dudit standard qui suscite des appels de certains intervenants à passer au langage Rust. En effet, la question de savoir si Rust est meilleur que le C++ pour la programmation des systèmes critiques fait l'objet d'un débat continu au sein de la communauté des ingénieurs logiciels au sens large, mais actuellement, il n'est pas utilisé dans les systèmes principaux du F-35.

C++ contre Rust : Et si le problème se situait plutôt entre la chaise et le clavier ?

C’est ce que suggère l’existence de la norme JSF C++. Elle contient 221 règles dont le programmeur a la charge de l’implémentation afin d’éviter les pièges courants du C++. Parmi les plus notables, on peut citer :

  • Pas d'exceptions : la gestion des exceptions C++ est entièrement interdite afin de garantir une exécution déterministe.
  • Pas d’allocation dynamique de mémoire : l'utilisation de malloc, free et new/delete est généralement interdite après l'initialisation afin d'éviter les fuites de mémoire et la fragmentation.
  • Pas de récursivité : la récursivité est interdite afin d'éviter les débordements de pile et de rendre le temps d'exécution prévisible.
  • Complexité limitée : chaque fonction doit être suffisamment simple (complexité cyclomatique ≤ 20) pour que tous les chemins de décision puissent être testés de manière approfondie.

L’existence de la norme JSF C++ est en phase avec un avis de Bjarne Stroustrup selon lequel ce qu’il est possible d’obtenir du C++ en matière de sécurisation des logiciels dépend entre autres du développeur et notamment de la connaissance des outils que lui offre le langage, de sa maîtrise du compilateur, etc. En droite ligne avec cette position, le créateur du C++ propose donc des Profils qui ont pour but de définir des modes de C++ qui imposent des contraintes sur la manière dont le programmeur utilise le langage et la bibliothèque, afin de garantir certaines propriétés de sécurité. Il s'agit principalement de contraintes au moment de la compilation, bien que dans la pratique, certaines vérifications puissent être mises en œuvre à l'aide de fonctionnalités de bibliothèque qui ajoutent une surcharge d'exécution limitée.

Au lieu d'introduire des constructions de langage entièrement nouvelles, les Profils limitent principalement les fonctionnalités et les utilisations existantes. L'idée est que vous pouvez activer un profil, et tout code qui l'utilise accepte de se conformer aux restrictions. Si vous ne l'activez pas, tout fonctionne comme avant. Il est donc rétrocompatible.


La récente adoption du Rust comme deuxième langage de programmation du noyau Linux aux côtés du C indique néanmoins que le Rust a du potentiel pour se positionner parmi les mastodontes de la programmation système

La prise en charge de Rust pour le développement du noyau Linux est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

De plus, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo. C'est pour ce lot de raisons que Mark Russinovich de Microsoft recommande le langage Rust plutôt que le C ou C++ dans le cadre des nouveaux projets.


Et vous ?

:fleche: Que pensez-vous de ces appels à réécrire la base de code C++ des avions F-35 en Rust ? Quels seraient les avantages d’une telle opération ?
:fleche: Partagez-vous les avis selon lesquels le problème n’est pas les langages de programmation mais la capacité des programmeurs à tirer le meilleur parti de ces derniers ?
:fleche: L'adoption du Rust comme deuxième langage de programmation du noyau Linux aux côtés du C est-elle un signal suffisamment fort pour que les nouveaux projets soient menés dès le départ non pas en C ou C++ mais en Rust ?
:fleche: Partagez votre expérience personnelle en programmation système avec Rust comme langage

Voir aussi :

:fleche: L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé
:fleche: Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D
:fleche: C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust ]]> Programmation système Patrick Ruiz https://www.developpez.net/forums/d2181039/general-developpement/programmation-systeme/avions-f-35-bannissent-90-fonctionnalites-cpp-obtenir-code-selon-googler/