Bien lire les données avant de vouloir bien calculer

Pize est un assistant de programmation IA pour le calcul scientifique et l’analyse statistique. Il fonctionne dans Pize Code et Positron, et est également proposé sous forme de SDK.

La plupart des agents de programmation consacrent leurs efforts à produire davantage de code. En statistique et en recherche, les erreurs surviennent généralement plus tôt : si les données sont mal lues, chaque test, modèle et inférence qui suit hérite discrètement de cette erreur. Pize intervient à ce niveau : il veille d’abord à ce que le modèle connaisse la forme, les types et les valeurs manquantes des données, puis il écrit et exécute du code, interprète les graphiques et apporte des corrections dans la session R / Python que vous utilisez déjà.

Pize est aussi un agent de programmation complet : modifications dans plusieurs fichiers, terminal, planification et exécution, règles de projet, choix de modèles et accès, via MCP, aux outils déjà présents dans un laboratoire ou un système interne. Utilisez-le dans Pize Code, Positron, avec la CLI ou via le SDK.

• Ce qu’est Pize. Un agent de programmation optimisé pour le calcul mathématique et l’analyse statistique. La lecture, le calcul et les tests ont lieu dans une session active. Les résultats peuvent être recalculés.
• Ce que Pize n’est pas. Ce n’est ni un outil générique de complétion de code simplement remaquillé, ni un substitut à Cursor qui écrirait un peu de tout. L’objectif n’est pas la complétion, mais la lecture correcte des données et la fiabilité des calculs.
• Où il fonctionne. Dans Pize Code, Positron, avec la CLI et via le SDK.
• Ce qui est transmis au modèle. La structure, les types, les valeurs manquantes et des résumés, plutôt que la table entière insérée dans le contexte. Les observations brutes restent dans la session.

Le même agent de programmation lit des fichiers, écrit du code, lance des commandes et peut piloter un navigateur. Chaque modification et chaque commande nécessitent votre approbation. Utilisez-le dans Pize Code, Positron, la CLI ou via le SDK.

Points d’accès disponibles

• Pize Code. Un plugin dans la barre latérale de l’éditeur. Modifications multi-fichiers, terminal, modes de planification et d’exécution, et diffs pouvant être relus.
• Positron. Le même agent, avec en plus un pont vers la session R ou Python déjà au premier plan.
• SDK. Le même agent intégré dans un programme que vous utilisez déjà, également disponible via la CLI.

Facturation de l’utilisation des modèles

L’utilisation en libre-service est réglée avec des crédits prépayés. Un crédit vaut un centime de dollar américain. Achetez un pack sur la page des tarifs ; Stripe encaisse le paiement. Les conditions entreprise sont convenues après prise de contact.

Entreprise

Aucun tarif n’est publié pour les laboratoires ni pour les conditions personnalisées. Ces conditions sont convenues après prise de contact.

C’est aussi un agent de programmation complet

La lecture des données et la passerelle de session constituent le niveau supplémentaire apporté par Pize. La suite présente les capacités de l’agent de programmation complet qu’il est également : sans elles, la boucle statistique ne peut pas fonctionner.

Un SDK (Software Development Kit, ou kit de développement logiciel) regroupe des API, des types et des exemples afin qu’un autre programme puisse appeler une fonctionnalité sans avoir à la réimplémenter.

Sans SDK, chaque intégration écrit ses propres appels HTTP et devine la signification des champs. Avec un SDK, le programme appelant dispose de noms de fonctions stables, de types et d’un exemple réellement exécutable. C’est à ce niveau qu’un modèle s’intègre dans un logiciel d’acquisition de laboratoire ou une plateforme d’analyse interne.

• Ce qu’il fournit. Des interfaces appelables, des types et le plus petit exemple fonctionnel. Le programme appelant n’a pas à réinventer la lecture des données ni la session.
• Ce qu’il ne fournit pas. Il ne remplace pas l’interface de votre produit et ne choisit pas la méthode statistique. La méthode reste proposée par le modèle et soumise à votre confirmation.
• Sa différence avec le plugin. Le plugin s’ouvre dans l’éditeur. Le SDK intègre le même agent dans un programme que vous utilisez déjà, sans ajouter de barre latérale.

MCP (Model Context Protocol) est un protocole ouvert : il permet à un modèle d’accéder, pendant l’exécution, à des outils, des données et des prompts externes, sans créer une connexion propriétaire pour chaque source.

Un modèle se limite au raisonnement. Il ne peut ni voir votre base de données ni manipuler les paramètres d’un logiciel d’instrumentation. MCP définit trois éléments : les outils (actions appelables), les ressources (données lisibles) et les prompts (instructions réutilisables). Tout système qui met en œuvre ce contrat peut être utilisé de la même manière par le modèle.

• Le problème qu’il résout. Le modèle et le système externe n’ont plus à inventer chacun une connexion propriétaire. Les bases de données, les bases de connaissances et les passerelles internes sont accessibles au moyen d’un protocole commun.
• Ce qu’il n’est pas. Ce n’est ni un modèle ni un SDK. MCP ne détermine pas comment intégrer l’agent dans votre propre programme ; il définit uniquement comment l’agent en cours d’exécution se connecte à l’extérieur.
• Dans Pize. Pize se connecte en tant que client à d’autres serveurs MCP. La limite de sécurité reste votre approbation : lecture seule par défaut et attente de votre confirmation avant toute action.

Pour qu’un système d’IA obtienne des résultats justes en recherche, il lui manque rarement « un modèle plus grand ». La question est de savoir si le modèle peut voir des données réelles, utiliser de vrais outils et fonctionner dans les logiciels que vous employez déjà.

Pize distingue ces trois niveaux tout en les reliant. Le modèle choisit une méthode et écrit le code. Le SDK place cet agent dans vos outils. MCP lui permet d’accéder, pendant l’exécution, aux bibliothèques, aux logiciels d’instrumentation et aux systèmes internes. La lecture reste la première étape : si les données sont erronées, les deux autres niveaux ne font que propager l’erreur.

Les erreurs statistiques se manifestent rarement par un plantage. Un mauvais séparateur décale toutes les colonnes ; prendre la première ligne pour un en-tête supprime la première observation ; traiter NA et NULL comme 0 modifie la moyenne et la variance ; une colonne numérique lue comme du texte devient un facteur dans un modèle de régression. Rien de tout cela n’arrête le programme. Il renvoie discrètement un chiffre erroné mais plausible — et, puisque l’erreur s’est produite à la lecture, tous les tests, modèles et inférences ultérieurs en héritent.

Pize n’est donc pas optimisé pour faire écrire davantage de code au modèle. Il lui fait d’abord connaître la forme des données, le type de chaque colonne, le nombre de valeurs manquantes et le nombre approximatif de lignes. Le modèle écrit ensuite le code de calcul et de modélisation, puis l’exécute dans votre session réelle afin que vous puissiez en voir les résultats.

La détection du format examine le contenu, et non l’extension du fichier : dans les données de recherche, un fichier .txt contient souvent un tableau, tandis qu’un fichier .csv peut ne contenir que trois lignes de configuration. Chacune des décisions ci-dessous influe directement sur les résultats obtenus ensuite.

• Détection du séparateur. Le séparateur est choisi parmi la tabulation, la virgule, le point-virgule et la barre verticale (|). Le nombre de colonnes doit rester stable d’une ligne à l’autre et les champs doivent ressembler à des cellules, afin qu’un texte comportant une virgule par phrase ne soit pas interprété comme un tableau à deux colonnes.
• En-tête ou données. Si la première ligne contient encore des chiffres aux emplacements de colonnes numériques, il s’agit d’une observation et non de noms de colonnes. Prendre la première observation pour l’en-tête est une cause classique de perte d’un échantillon.
• Les valeurs manquantes restent hors de l’inférence de type. Les chaînes vides, NA, NaN et NULL sont reconnues séparément ; sinon, une colonne entièrement vide peut être typée comme numérique et amener le modèle à résumer des nombres inexistants.
• Inférence de type colonne par colonne. Numérique / texte / vide, colonne par colonne. Cette étape décide si une colonne peut entrer dans une moyenne, une variance ou une régression.
• Commentaires et métadonnées sont retirés. Les blocs initiaux qui commencent par #, ! ou @XX partent d’abord. VCF cache les noms de colonnes dans la dernière ligne de commentaire ; ils sont récupérés pour que les colonnes aient un nom.
• Les tableaux compressés sont lus de façon transparente. Les fichiers .gz sont décompressés automatiquement ; leur taille est évaluée après décompression — une archive de 1 Mo peut contenir un tableau de 20 Mo.
• Estimation du nombre de lignes. Le total s’estime d’après la part en octets du préfixe déjà lu, et le chiffre est étiqueté comme estimation, pas comme fait.
• Un fichier hors budget reçoit une fiche de données, pas une erreur. Si le budget de contexte est dépassé, Pize renvoie la taille, le séparateur, le nombre estimé de lignes, les noms de colonnes avec leurs types inférés et les deux premières lignes. Le modèle peut alors écrire le bon code de lecture sans qu’un tableau d’un million de lignes n’épuise le contexte.

On lit d’abord, on calcule ensuite. Pize n’invente pas de méthodes statistiques à votre place. Il garantit que le modèle voit vos vraies données, et que vous voyez chaque étape.

• Choisir la méthode d’après la distribution réelle. Le modèle reçoit le nombre de lignes et de colonnes, les types, le nombre de valeurs manquantes et les statistiques de synthèse. Il s’en sert pour choisir entre une méthode paramétrique et non paramétrique, décider d’une éventuelle transformation et traiter les valeurs manquantes.
• Écrire, puis exécuter. Le R ou Python généré s’exécute dans la session courante après votre accord. Ce qui revient est une vraie sortie, pas un résultat imaginé.
• Diagnostiquer sur les graphiques. Le dernier graphique peut être récupéré — QQ, résidus, distributions, que l’on ne juge qu’en regardant. Le modèle peut participer à ce jugement.
• Itération fermée. Exécuter, lire, corriger, dans la même session. Les variables intermédiaires ne se perdent pas parce qu’un autre processus a démarré.
• Agrégats seulement, jamais les lignes brutes. Les synthèses de table renvoient structure et statistiques. Les observations brutes restent dans la session.

La vérité d’une analyse n’est pas dans le fichier, elle est en mémoire. Le pont lit, via l’API publique d’extension de Positron, la session R ou Python actuellement au premier plan. Il ne crée ni ne change de runtime. Il n’utilise que celui que vous employez déjà.

• Tests de non-régression sur des corpus générés. Des échantillons étiquetés sont générés pour 31 formes de fichiers, par lots de dix mille, puis soumis au détecteur. Le premier passage a échoué sur 458 cas et révélé quatre catégories de défauts, corrigées une à une. La graine aléatoire est fixe, ce qui permet de vérifier avec les mêmes entrées que les défauts corrigés ne réapparaissent pas.
• Des tests sentinelles à chaque point d’intégration. Chaque point d’intégration avec le code amont dispose d’un test. Si une fusion supprime une seule ligne de raccordement, le test échoue immédiatement : la fonctionnalité ne peut pas cesser de fonctionner en silence tandis que la suite de tests reste au vert.
• La liste complète à chaque fusion. Des milliers de tests unitaires, deux vérificateurs de types, un lint de tout le dépôt ; après empaquetage, l’artefact s’ouvre pour confirmer que le comportement est bien dedans.
• Auto-contrôle en un clic. Le contrôle de pont de la palette de commandes lit vraiment une session. Un succès prouve que les outils ont atteint de vraies données.
• Coexiste avec la version officielle. Publié sous un identifiant d’extension distinct, installable à côté du plugin amont sans l’écraser.

L’architecture suit une règle constante : tout nouveau comportement est placé dans de nouveaux fichiers, et les fichiers amont ne sont modifiés qu’aux points d’appel nécessaires. Ainsi, une fusion couvrant dix commits amont peut ne produire qu’une seule ligne de conflit. Le projet peut continuer à suivre l’amont au lieu d’être publié une fois puis de rester figé.