« La prochaine version du smartphone » : Sam Altman dévoile sa vision du téléphone à l’ère de l’IA

OpenAI a présenté le 10 novembre Control Room, un système central qui suit toutes les tâches de ses chercheurs utilisant ses modèles d’IA.

Avec Businesses in ChatGPT, OpenAI permet aux entreprises de revendiquer leur fiche dans le chatbot, d'y corriger leurs infos et de savoir combien de fois elles y sont citées. Certaines pourront même y installer leur propre agent conversationnel. Si ChatGPT est le « Google » de 2026, vous avez toutes les raisons de créer votre fiche.
À l’échelle agentique, un système où chaque nœud héberge une copie complète et autonome de l’historique Git n’est plus viable.
Anthropic, Cursor, GitHub et OpenAI s’accordent sur ce point. Chacun a entrepris de faire évoluer son système de gestion de versions en abandonnant le modèle purement décentralisé.
Sur son monorepo interne, Anthropic est passé d’environ 2500 merges par jour en mai 2026 à plus de 30 000 en septembre. Avec un historique principal avoisinant 100 Go et près de 25 millions d’extractions quotidiennes pour le CI, l’utilisation classique de Git aurait exigé de transférer plus de 600 Po de données par jour. Le palliatif consistant à exécuter des centaines de miroirs et de snapshots de dépôts sur stockage objet était devenu ingérable.
Anthropic a opté pour une rupture avec Git. Il l’a remplacé par un système maison baptisé Scion et développé en 5 mois.
Exit, donc, le modèle décentralisé. Le serveur gère les opérations lourdes (merges, rebases, création des commits…) tandis que le client local se résume à une couche légère gérant un cache borné et la matérialisation à la demande des fichiers sur le disque.
Contrairement à un commit Git pointant vers un arbre complet d’objets, le changeset de Scion ne stocke que la liste des fichiers modifiés par rapport au premier parent. Cette liste est associée à des pointeurs adressés par contenu vers des blobs compressés.
De Git, Scion supprime aussi les packfiles. Il n’utilise, en parallèle, aucune copie totalement matérialisée du dépôt. La création d’un changeset s’effectue en temps proportionnel à la taille de la modification – et non à la taille du dépôt. Les références globales (branches, tags) sont strictement découragées hors de la branche principale ou des versions. Leur mise à jour se fait par CAS (compare-and-swap) sur une ligne de base Spanner.
Pour calculer rapidement le blame ou les graphes de commits, Scion génère des « données dérivées » (skip lists, index de chemins) définies récursivement et calculables à la demande. Le système expose ces primitives par API. CI et outils internes peuvent ainsi effecteur des requêtes sans cloner en local.
Le client communique via un socket avec un démon de nœud qui interroge des caches mémoire régionaux. Ces derniers s’alimentent auprès de serveurs d’autorité adossés à Spanner et au stockage objet. Un hiérarchie qui isole les pannes et supprime les protocoles de négociation de Git.
Anthropic affirme que cette infra consomme 200 fois moins de ressources calcul et mémoire que son ancienne flotte Git. Il ajoute que la CI a gagné 25 % de capacité CPU, avec des checkouts qui s’effectuent désormais en quelques secondes.
| Source de vérité | Spanner et GCS |
| Modèle de cohérence | Append-only (changesets) sur Spanner, données dérivées asynchrones |
| Écritures | Aucun push, commits créés côté serveur sans verrou |
| Format de transfert | Arbres et blobs individuels adressés par contenu |
| Compaction | Éliminée (aucun packfile, aucun repacking) |
Cursor a conservé le format de stockage et les outils natifs de Git sur disques NVMe locaux. Pour surmonter les limites de Spokes (architecture historique de réplication de GitHub), il a conçu un moteur alternatif nommé Continuity. Il l’a appliqué à son monorepo et à une flotte de micro-dépôts.
Son architecture est centrée sur un concept propre à S3 : les journaux d’écriture anticipée (WAL, Write-Ahead Logs). Lesquels consistent, dans les grandes lignes, à stocker plusieurs objets dans un même fichier de manière séquentielle. Ici, chaque push prend la forme d’une entrée de WAL distincte. Aucun push n’est acquitté tant qu’il n’est pas persisté sur S3. Un fichier d’index de WAL mis à jour par CAS linéarise chaque transaction.
Les répliques sur disques NVMe locaux ne sont que des caches qu’on réhydrate depuis le WAL. La localisation des dépôts ne dépend pas d’une base relationnelle centrale. Si un nœud tombe ou qu’un dépôt n’est pas présent localement, il est matérialisé depuis le WAL.
N’importe quel nœud peut recevoir une écriture et agir comme primaire. L’atomicité du CAS sur S3 garantit l’intégrité. La propagation des lectures se fait via un commérage UDP, chaque réplique vérifiant son état contre la source de vérité.
Continuity monte à 120 pushs par seconde sur S3 Standard ; à plus de 300 avec S3 Express One Zone. On atteint ensuite la limite intrinsèque de vitesse de compaction Git sur disque. En lecture, le système a démontré une montée en charge linéaire jusqu’à 100 répliques sans impacter les écritures.
| Source de vérité | WAL S3 |
| Modèle de cohérence | Stricte et linéarisable via index S3 |
| Écritures | Locale + S3 en parallèle, linéarisée par CAS sur l’index S3 |
| Format de transfert | Packfiles classiques |
| Compaction | Repackaging asynchrone sur répliques découplées |
En deux ans, le volume de commits atterrissant sur la branche master du monorepo d’OpenAI a été multipliée par 25 environ. La fiabilité du contrôle de version était passée sous les 90 %. En 10 semaines, l’entreprise a développé Pando.
Ce back-end rejette l’idée qu’un serveur doit fournir un état cohérent de l’ensemble des branches à un instant T lors d’un clone ou d’un fetch. Les mises à jour de chaque branche sont indépendantes et sérialisables individuellement, mais Pando remplace le snapshot global par un modèle de cohérence causale. Un client qui récupère une branche respecte l’historique de l’auteur qui l’a créée, sans que le système impose d’ordre d’interclassement global avec les branches non liées. Deux clients qui lisent différentes branches au même moment peuvent donc voir des versions décalées dans le temps.
Traditionnellement, chaque fetch oblige le serveur à calculer dynamiquement la différence entre les objets que détient le client et ceux demandés. Puis à compresser un packfile sur mesure. Pando réutilise des packfiles immuables préexistants. Les serveurs n’ont par conséquent plus à recalculer de deltas à la volée.
Lors d’un push, le packfile qu’envoie le client est validé en une seule passe et streamé directement vers le stockage objet, sans déballage local. Une transaction enregistre une « version de référence » dans le magasin de métadonnées et bascule le pointeur de la branche de façon atomique. Lors de la phase de négociation du push, Pando n’annonce pas l’intégralité de ses branches. Cela évite de créer des packs trop interdépendants ou trop fragmentés.
Pour transférer les données, Pando utilise packfile-url, directive Git qu’OpenAI a perfectionnée en amont dans le projet open source. Lors d’un fetch, la réponse HTTP principale renvoie un packfile vide accompagné d’une liste d’URI pointant vers les packfiles requis. Les clients téléchargent ces packs depuis Express, un service de cache régional distribué. Cela permet de maximiser l’usage de la bande passante réseau sans solliciter le CPU sur le serveur.
Chaque push génère un pack de niveau L0. Des processus en tâche de fond regroupent géométriquement l’ensemble des packs en couches supérieures (L1 à L4) pour améliorer la compression et accélérer les extractions.
OpenAI explique que Pando a réduit la latence médiane des pushs de près de 80 %. Et qu’il permet de délivrer près de 1 Po de données Git par jour avec « une poignée » de cœurs CPU.
| Source de vérité | Stockage objet immuable + magasin de métadonnées |
| Modèle de cohérence | Cohérence causale |
| Écritures | Streaming direct vers le magasin d’objets sans décompression locale |
| Format de transfert | Packfile vide inline + URI de packfiles précompressés réutilisables |
| Compaction | Hiérarchique multiniveaux façon LSM-Tree (L0 à L4) |
En un an, le volume de commits qu’a enregistrés GitHub a plus que quintuplé : 7,38 milliards en septembre 2026, pour 3,35 milliards de pushs.
L’architecture qu’il a commencé à déployer en production minimise la coordination. Le quorum et le protocole 3PC (verrouillage des commits en 3 étapes) ne portent plus sur l’ensemble du dépôt. Ils sont isolés au niveau de chaque référence (branche) individuelle. Les agents qui travaillent en parallèle sur des branches distinctes ne subissent plus de contention mutuelle. Les étapes lourdes (écriture des objets, validation de connectivité, analyse des secrets) se déroulent hors du chemin critique. L’étape de coordination se réduit donc au déplacement du pointeur de référence. Les tests internes ont démontré un débit d’écriture 3 à 4 fois plus élevé sur les dépôts concurrents.
Comme ses pairs, GitHub a découplé le stockage du calcul. Il a confié les données d’autorité au stockage objet Azure. Un nœud de calcul éphémère intègre le quorum de vote comme passerelle. Il streame les écritures, agrège les transactions de branches disjointes en un nombre réduit d’E/S, puis s’occupe de la compaction. D’autres nœuds temporaires sont instanciés à la demande pour absorber les pics de lecture. Ils réconcilient leur cache en arrière-plan avec Azure Blob Storage. Des workers indépendants gèrent le décompactage, le repacking et le nettoyage des objets orphelins.
Dans son architecture cible, GitHub annonce un gain potentiel de débit d’écriture allant jusqu’à un facteur 35. Tout en assurant une montée en charge autonome de la couche de lecture.
| Source de vérité | Azure Blob Storage |
| Modèle de cohérence | Forte via quorum délimité par référence |
| Écritures | Concurrentes sur branches disjointes via quorum par référence |
| Format de transfert | Packfiles classiques |
| Compaction | Workers d’arrière-plan isolés du chemin critique |
Illustration générée par IA
The post Anthropic, Cursor, GitHub, OpenAI : 4 approches pour passer Git à l’échelle agentique appeared first on Silicon.fr.


Trois actualités à retenir cette semaine dans le cyberespace, un modèle d’OpenAI qui corrige un autre modèle en retouchant directement ses paramètres, un projet open source majeur dépassé par le nombre de bugs que l’IA lui signale, et OpenAI qui affirme avoir industrialisé la recherche de failles dans le noyau Linux.

La Nasa jette un froid sur le mythique avion SR-71 Blackbird, EDF déploie de nouveaux horaires d'heures creuses auprès de ses clients, la preuve mathématique secrète d'OpenAI bientôt publiée : c'était l'actualité scientifique de la semaine.
OpenAI dévoile GPT-6 Cyber, une variante spécialisée de son modèle d’IA GPT-6, conçue pour la cybersécurité. Selon l’entreprise, le système a atteint le niveau « critique », le plus élevé dans sa classification des capacités en cybersécurité. Lors de tests, il a reproduit 1 724 vulnérabilités du noyau Linux et développé des exploits fonctionnels pour […]
Cet article GPT-6 Cyber : la nouvelle IA d’OpenAI capable d’exploiter près de 1 000 failles dans Linux est apparu en premier sur Trust My Science.

La taxe sur les gigaoctets a connu un fort écho médiatique, jusqu'au rejet du projet de loi des finances lors de son examen à l'Assemblée nationale. Mais ce n'est peut-être que partie remise... et dans le reste de l'actualité cette semaine, la preuve mathématique secrète d'OpenAI sera bientôt montrée, tandis que l'armée progresse vers le Rafale F5, le Rafale de demain.
OpenAI ne veut plus seulement concevoir des modèles capables d’écrire du code, de produire des images ou d’automatiser des tâches bureautiques. L’entreprise américaine entend désormais les mettre au travail dans l’un des domaines les plus complexes de l’ingénierie : la conception de semi-conducteurs.

Voilà un chiffre qui ne devrait pas manquer de faire grincer des dents chez Google. Lors d’un récent événement presse, Adam Fry, responsable produit grand public de ChatGPT chez OpenAI, a assuré que le volume de requêtes de recherche transitant par le chatbot d’intelligence artificielle équivalait à 20 % de celui du géant de Mountain View. Il avait déjà avancé cette proportion dans un entretien accordé quelques jours plus tôt.
L’annonce s’ajoute à une série de statistiques d’usage que l’entreprise distille volontiers. ChatGPT compte 1,2 milliard d’utilisateurs actifs chaque semaine, dont environ 200 millions gagnés en l’espace de deux mois. Ses modèles produiraient près de 1,5 milliard d’images par semaine pour le compte des utilisateurs. La fonction ChatGPT Voice, qui permet de converser à l’oral avec l’assistant, toucherait environ 250 millions de personnes.
Tout dépend évidemment de ce que l’on compte. OpenAI retient comme recherche toute requête qui déclenche une consultation du web. Les demandes de définition d’un terme ou d’explication pratique simple sont donc exclues du calcul. Adam Fry parle de « tout ce pour quoi un utilisateur serait autrefois allé sur un moteur de recherche classique, mais pour quoi il choisit désormais ChatGPT ». Il a été plus direct encore. « Chaque fois que vous posez une question et que l’outil va chercher sur le web, c’est une recherche. »
Le moins que l’on puisse dire, c’est que la définition est large. Elle peut englober à peu près toutes les interactions au cours desquelles ChatGPT va puiser une information en ligne. Le flou ne s’arrête pas là. Adam Fry n’a indiqué ni le nombre absolu de requêtes concernées ni l’origine du chiffre de volume de Google qui sert de base à la comparaison. Nous sommes donc face à un ratio dont on ignore aussi bien le numérateur que le dénominateur.

Pour donner une idée de l’échelle, faisons le calcul. Si Google traite 16 milliards de recherches par jour, 20 % de ce volume représenteraient environ 3,2 milliards de requêtes quotidiennes du côté de ChatGPT. Il s’agit évidemment d’une simple extrapolation, OpenAI n’ayant avancé aucun chiffre de ce type. Rappelons que Google détiendrait plus de 90 % des parts du marché mondial des moteurs de recherche, outils d’IA mis à part.
La comparaison avec Microsoft éclaire toutefois la portée de l’annonce. En 2023, lors du procès antitrust visant Google, Satya Nadella, PDG de Microsoft, avait reconnu que Bing plafonnait à environ 3 % de parts de marché, et ce après plus de dix ans d’efforts. Notez au passage qu’OpenAI s’appuie vraisemblablement sur Bing pour une bonne partie de ses recherches, en complément de son propre index.
Le parcours d’OpenAI dans ce domaine n’a pourtant rien d’une ligne droite. SearchGPT, présenté à l’origine comme un moteur de recherche autonome, a fini par être fondu dans ChatGPT. ChatGPT Atlas, le navigateur maison pensé pour concurrencer Chrome, a été abandonné sans tambour ni trompette plus tôt cette année, faute d’avoir su séduire les utilisateurs.
OpenAI mise désormais sur une interface visuelle et interactive intégrée directement aux réponses du chatbot, baptisée « Intelligent UI ». « C’est dans cette direction que va l’avenir de cette technologie. Vous parlez à un canevas », résume Adam Fry.
Ce volume de recherche a aussi une valeur commerciale évidente. L’entreprise voit dans la publicité une piste possible vers la rentabilité, alors qu’une introduction en Bourse pourrait intervenir dès le début de l’année prochaine. Le mois dernier, elle a annoncé que ChatGPT afficherait des images de produits et de services sponsorisés. Jusqu’ici, les annonceurs devaient se contenter de leur nom, de leur logo et d’un lien. Adam Fry se veut rassurant sur ce point. Selon lui, « la publicité n’a eu aucun effet négatif sur le produit ni sur son utilisation » et « la plupart des gens ne semblent pas gênés par la présence de publicités ».
Les abonnements restent l’autre levier, bien qu’OpenAI semble peiner à l’activer. Car même en ajoutant 10 millions d’abonnés au dernier chiffre public, la part d’utilisateurs payants plafonnerait autour de 5 %. Interrogé sur ce point, Adam Fry s’est contenté de rappeler le cap des 50 millions d’abonnés payants. Il a assuré que ce chiffre avait progressé depuis, sans préciser de combien.
Comme vous le savez, je m'amuse beaucoup avec l'IA en ce moment. Bon, j'en cause surtout sur mon Patreon parce que sinon, je vous saoulerai grave avec toutes mes expériences mais ça c'est un truc que je tenterai bien à l'occasion. Je vous explique...
Cette semaine, 4 chercheurs du MIT CSAIL, Rikiya Takehi, Jayden Teoh, Alex Zhang et Omar Khattab, ont expliqué sur leur site comment ils ont demandé à GPT-6 Astra, le modèle d'OpenAI, de rendre Qwen3.5-0.8B meilleur en maths en retouchant directement ses poids, sans la moindre descente de gradient.
Et non seulement, l'IA d'OpenAI y est parvenu, mais en plus, le chiffre claque puisque le score sur MATH-500 de ce Qwen est passé de 7,9 % à 48,1 % suite à une modification par Astra de seulement 131 072 poids sur 0,8 milliard, soit 0,016 % du modèle.
Pour ceux qui arrivent (en armure comme Diam's ^^), les poids d'un réseau de neurones, c'est l'IMMENSE liste des nombres que l'entraînement ajuste petit à petit, et que presque personne ne sait ensuite retoucher à la main. C'est d'une telle complexité ! Mais avec un petit budget et 50 passes pour regarder comment le modèle répond à ses retouches, Astra lui à réussi !
Le point de départ des chercheurs, c'est que Qwen tournait en rond sur les problèmes de maths. Ainsi sur ses 96 premières réponses d'entraînement, 85 pédalaient dans la semoule jusqu'à atteindre la limite des 32 768 tokens et donc sans livrer de solution... Snif... Astra a donc remonté ces boucles une par une jusqu'à une direction écrite par les couches 15 et 19 du modèle, puis il l'a soustraite des poids. Et voilà comment la part des réponses interrompues à cause de cette limite en token est tombée de 93 % à 33 %.
Alors, Qwen est-il vraiment devenu bon en maths grâce à Astra ?
Hé bien pas vraiment, et ce sont les auteurs eux-mêmes qui le disent dans leur papier. En fait, réparer des boucles permet surtout au modèle de finir des réponses qu'il savait déjà trouver. Ils ont d'ailleurs refait l'essai sur Gemma 3 270M, un modèle qui boucle rarement, et là, aucune des retouches d'Astra n'a fait bougé le score MATH-500 de plus d'un point. Voilà, donc contrairement aux grandes annonces que j'ai pu lire de ci, de là, retoucher les poids de Qwen a juste permis de lever un obstacle qui cachait une capacité existante, mais n'a en aucun cas ajouté une capacité qui manquait.
Cette expérience a ensuite été refaite par Jonathan Coletti, sur Hugging Face, qui a réévalué les poids publiés avec le prompt, les réglages et le correcteur des auteurs. Et il est passé d'un Qwen à 7,4 % à un Qwen à 50,2 % après, réflexion activée bien sûr (le mode "Thinking" quoi). Ça confirme donc bien le papier.
Mais Jonathan a aussi tenté le coup avec le mode réflexion coupé et là, la retrouche a fait perdre au modèle un peu plus de 2 points.
Quoiqu'il en soit, cette retouche peut se rapprocher de l'effacement d'une direction dans les poids, ce qui en gros est la recette de l'abliteration qu'utilisent déjà ces outils qui virent la censure des LLM . Astra serait donc potentiellement capable de lever des limites sur des modèles open source (dont les poids sont dispo)... Intéressant non ?
Voilà, donc si vous faites tourner ce petit Qwen chez vous et que vous optez pour cette version retouchée par Astra, activez bien ce mode Thinking car avec lui, le modèle aura la bosse des maths !
Source : Sparks of Weight-Space Programming
