Notre approche Open Source

Le logiciel natif IA n’est pas construit uniquement derrière des pages de produits fermées. Les outils utiles commencent souvent par des expériences, des utilitaires de développement, des flux de travail locaux, des prototypes ou des surfaces d’exploitation qui peuvent aider d’autres builders bien avant qu’ils ne deviennent des produits raffinés.

inAi publie ouvertement des outils sélectionnés lorsqu’ils sont utiles au-delà de notre propre travail, compréhensibles à partir du référentiel et partagés publiquement en toute sécurité. Certains projets prennent en charge les produits que nous construisons. Certains explorent les interfaces de l’ère des agents, les flux de travail locaux, la génération de médias IA, la parole, la conversation ou les surfaces d’exploitation. Certains sont des projets de référence plus anciens, rendus publics car ils contiennent encore des idées utiles.

Open Source ne représente pas l’ensemble de l’entreprise et ce n’est pas une promesse que chaque système interne deviendra public. Cela fait partie de la manière dont inAi introduit l’IA dans le monde réel : en proposant des outils pratiques où l’ouverture crée de la valeur, tout en protégeant les systèmes de produits privés, les données sensibles, les infrastructures sensibles à la sécurité et l’architecture interne.

IA devient une nouvelle couche d’exploitation pour les logiciels et le travail. Ce changement ne sera pas déterminé uniquement par les produits finis. Il sera également façonné par des outils, des interfaces, des prototypes, des utilitaires locaux, des flux de travail des développeurs, des expériences et des implémentations de référence publique qui aident les gens à comprendre ce qui est possible.

Lorsqu’un outil peut être utile en dehors d’inAi, nous préférons laisser les gens l’inspecter, l’exécuter, l’adapter, en tirer des leçons ou y contribuer. Open Source permet aux travaux utiles de voyager plus loin qu’un référentiel privé. Cela donne aux développeurs et aux chercheurs quelque chose de concret à examiner. Cela donne aux partenaires techniques une idée plus claire de la façon dont nous construisons. Cela donne à l’écosystème au sens large plus de matériel avec lequel travailler.

Open Source n’est pas seulement un canal de publication. C’est une façon de travailler avec les personnes qui construisent, testent, inspectent, étendent et remettent en question la technologie.

Nous publions des outils sélectionnés car d’autres personnes peuvent trouver des utilisations que nous n’avions pas prédites. Les développeurs peuvent améliorer un flux de travail. Les chercheurs peuvent inspecter un détail de mise en œuvre. Les utilisateurs peuvent adapter un utilitaire à leur propre processus local. Partenaires pourrait constituer un point de départ pour une collaboration. Les contributeurs peuvent aider à faire avancer un projet ou à identifier les domaines dans lesquels un prototype doit être plus robuste.

Cette posture communautaire ne nécessite pas de prétendre que tout est public ou pleinement mature. Cela nécessite de la clarté : ce que fait le projet, dans quel état il se trouve, comment il peut être utilisé, ce qui est expérimental, ce qui est hérité et où la collaboration a du sens.

Le travail Open Source d’inAi couvre plusieurs types de logiciels natifs IA. Certains projets sont une infrastructure de développement pour les flux de travail de l’ère des agents. Certaines sont des applications locales qui aident les utilisateurs à exécuter des tâches IA sur leurs propres machines. Certains explorent les workflows créatifs ou multimédias. Certains expérimentent la parole, la traduction, la conversation ou les interfaces portables. Certains conservent les anciens prototypes et utilitaires de flux de travail IA car ils restent des références utiles.

Le modèle commun ne correspond pas à un seul type de produit. Le modèle commun est l’utilité : des outils qui peuvent aider les gens à construire, inspecter, automatiser, prototyper, apprendre ou travailler plus directement avec les systèmes IA.

Tous les outils internes ne doivent pas être rendus publics. Certains outils sont trop liés à des systèmes de produits privés. Certains contiennent des détails de mise en œuvre sensibles. Certains dépendent des données des clients, fournisseurs, candidats ou partenaires. Certains ne sont utiles que dans inAi. Certains nécessitent davantage de nettoyage avant que quiconque puisse les comprendre ou les exécuter.

C’est pourquoi notre portefeuille Open Source contient un mélange d’outils actifs, d’expériences, d’utilitaires de référence et de projets existants. L’ouverture est précieuse lorsqu’elle crée de la valeur. Le contrôle est nécessaire lorsque le contrôle protège les utilisateurs, les partenaires, les produits ou les systèmes sensibles.

Chaque projet du portefeuille Open Source doit être lu via son étiquette d’état. L’étiquette n’est pas une décoration. Il indique aux visiteurs quel type de référentiel ils consultent et quelles attentes sont raisonnables.

Certains projets sont actifs. Certains sont expérimentaux. Certaines sont des références utiles. Certains sont des prototypes plus anciens qui restent publics car ils présentent une idée, un flux de travail ou un modèle de mise en œuvre qui mérite d’être préservé.

Les étiquettes claires nous permettent de libérer plus de travail sans prétendre que chaque référentiel a le même objectif. Ils rendent également le portfolio plus utile : un développeur peut décider d’exécuter, d’inspecter, d’adapter ou simplement d’apprendre d’un projet en fonction de son état actuel.

La page du portefeuille Open Source répertorie les projets publics détenus par inAi : des référentiels que nous maintenons et présentons dans le cadre de la catégorie inAi Open Source.

Cela est différent des contributions aux écosystèmes. Le logiciel natif IA dépend d’une infrastructure partagée : recherche et récupération, passerelles de modèles, interfaces de fournisseur, outils, protocoles, flux de travail des développeurs et autres éléments de base ouverts. Lorsque inAi contribue à des projets externes ou à des infrastructures écosystémiques, ces contributions doivent être décrites séparément des référentiels détenus.

La distinction est importante. Les projets détenus font partie du portefeuille public d’inAi. Les contributions à l’écosystème consistent en une participation à une infrastructure plus large dont de nombreux builders de l’IA peuvent dépendre. Les deux peuvent avoir leur importance, mais ils ne doivent pas être présentés comme la même chose.

Une partie croissante du logiciel IA n’est pas conçue uniquement pour les humains qui cliquent sur des écrans. Les agents et les flux de travail assistés par IA ont besoin d’outils qu’ils peuvent appeler, inspecter, réutiliser et exploiter avec des limites plus claires.

C’est pourquoi l’Open Source se connecte naturellement au Produits pour agents. Les outils publics peuvent exposer le fonctionnement des flux de travail de l’ère des agents : surfaces appelables, actions structurées, exécution locale, sorties révisables, statut des tâches, inspection différentielle, portes de sécurité et limites explicites autour de ce que le système est autorisé à faire.

PatchBay est le pont public actuel le plus solide entre ces deux zones. Il s’agit avant tout d’un projet Open Source, mais il montre également le type d’outils de l’ère des agents qui intéresse inAi : un logiciel que les flux de travail assistés par IA peuvent utiliser de manière plus contrôlée, inspectable, coordonnée et révisable.

La recherche peut devenir trop abstraite si elle ne touche jamais aux logiciels fonctionnels. Open Source donne à certaines idées une surface concrète : un référentiel, un flux de travail, un prototype, un utilitaire ou un outil que les gens peuvent inspecter.

Cela ne signifie pas que chaque projet Open Source est un résultat de recherche. Cela signifie que les outils publics peuvent prendre en charge la culture de recherche plus large autour des systèmes natifs IA, des flux de travail agents, des logiciels locaux, de la conception d’interfaces et des opérations pratiques IA.

Pour inAi, cela est important car notre vision du intelligence est systémique. Les modèles, les outils, la mémoire, l’exécution, les commentaires, les interfaces et les environnements comptent tous. L’Open Source peut exposer des éléments sélectionnés de ce monde logiciel plus large sans transformer l’architecture privée en matériel public.

Open Source n’est pas réservé aux personnes qui savent déjà exactement ce qu’elles recherchent. Les référentiels publics peuvent également aider les utilisateurs à découvrir comment les outils IA sont créés, où se situent leurs limites et pourquoi la maturité est importante.

Qui connecte Open Source à L’IA pour tous. La conversation publique autour de l’IA est souvent trop abstraite, trop craintive ou trop promotionnelle. De vrais outils rendent la conversation plus concrète. Ils montrent que le logiciel IA n’est pas magique : il possède des interfaces, des entrées, des sorties, un état, des autorisations, des journaux, des échecs, des tentatives et des choix de conception.

Tous les lecteurs n’inspectent pas le code. Mais même des pages de projet claires, des étiquettes honnêtes et des explications simples peuvent aider davantage de personnes à comprendre comment l’IA passe de la recherche ou des démonstrations à un logiciel pratique.

Open Source est une façon d’instaurer la confiance, mais ce n’est pas la seule. Une certaine confiance vient du code public, des étiquettes claires et des outils inspectables. Une certaine confiance vient des limites du produit, de la confidentialité, des documents juridiques, des preuves, de l’examen ou de l’accès contrôlé. Différents types de logiciels IA nécessitent différents modèles de confiance.

Notre posture Open Source suit le même principe : diffuser des outils sélectionnés là où l’ouverture crée de la valeur, et garder privé ce qui devrait le rester. Les éléments internes du produit, les données sensibles, l’infrastructure sensible à la sécurité et l’architecture interne ne deviennent pas publics simplement parce que inAi possède une catégorie Open Source.

L’objectif n’est pas une exposition maximale. L’objectif est une ouverture utile avec des limites claires.

Chaque référentiel inclut ses propres détails de licence et d’utilisation sur GitHub.