DocMeThis a été initialement développé pour Python. Ce choix permet une analyse statique précise des signatures, docstrings, paramètres, retours et structures de code. La prise en charge des langages suivants est prévue courant 2026 : Java, JavaScript, TypeScript, C++, PHP et Ruby. Inscrivez-vous à notre infolettre pour être informé(e) de l’arrivée des nouveaux langages.

Non. DocMeThis complète vos tests et vos linters. Les tests vérifient que le code fonctionne. Les linters vérifient sa forme. DocMeThis vérifie que la connaissance transmise par la documentation reste alignée avec le code. En fait, il est fortement conseillé d'appliquer Ruff avant DocMeThis.

La GitHub Action CI Check et les composants nécessaires à son fonctionnement sont ouverts et publiés sous licence MIT. Par ailleurs, nous pratiquons des tarifs fortement préférentiels pour les projets OSS — et en particulier la gratuité des deux premiers niveaux de nos solutions CI Fix et Audit.

DocMeThis est tout à fait compatible avec l’analyse de bases de code confidentielles. Selon le niveau de sensibilité, l’analyse peut être réalisée via cloud souverain, runner auto-hébergé, intervention sur site, voire environnement strictement air-gapped. L’audit repose sur une analyse statique : l’application n’a pas besoin d’être exécutée. DocMeThis ne conserve jamais le code fourni par le client.

Vous recevez un rapport priorisé indiquant la couverture documentaire, les incohérences code/doc, les zones de dette par module et les corrections à traiter en priorité, ainsi que la liste complète des symboles à documenter.

L’offre CI Check sert à détecter les dérives documentaires dans la CI, commit après commit. L’offre Audit sert à obtenir une vue d’ensemble de la dette documentaire d’un projet : couverture, zones critiques, incohérences et priorités de correction.

L’offre CI Check est elle-même sous licence MIT, et gratuite sans condition.
Les deux premiers niveaux de l’offre CI Fix sont gratuits pour les projets open source. Un tarif préférentiel sera appliqué au-delà, sur devis.
Les deux premiers niveaux de l’offre Audit sont gratuits pour les projets open source.
L’offre premium Build reste payante, avec tarifs préférentiels, sur devis.

Un crédit documentaire est l’unité utilisée par DocMeThis pour quantifier l’utilisation des ressources. Concrètement, le fait de documenter un symbole (classe, fonction, etc.) vaut 3 crédits, et chaque élément documentaire (paramètre, retour, etc.) au sein du symbole vaut 1 crédit. Ce mode de calcul est justifié par la complexité de l’AST.

Exemples :
- PR avec une fonction de deux paramètres et un retour : 3 + 2 + 1 = 6 crédits ;
- PR avec une classe, trois méthodes dont une avec quatre paramètres et un raise : 3 + 3×3 + 4 + 1 = 17 crédits.

Les crédits sont renouvelés mensuellement. Si le quota est atteint, les prestations CI Fix sont suspendues avec un message PR/MR neutre. Vous pouvez compléter votre abonnement avec un pack de 500 crédits supplémentaires pour 9 € (valable 12 mois, consommé après les crédits mensuels).

Le dépassement du quota CI Fix n’a bien évidemment aucun impact sur l’exécution de CI Check, et ne bloque pas la CI, sauf configuration explicite.

Non, pas sans validation. Les offres de détection signalent les problèmes. Les offres de génération proposent des corrections documentaires, mais celles-ci doivent être validées avant intégration. La validation peut être automatisée, mais cela reste votre choix.

Les outils CI Check et CI Fix sont conçus pour la maintenance incrémentale : mesurer la dérive documentaire dans la CI et corriger les docstrings au fil des PR/MR.
CI Check possède un mode d’évaluation permettant d’obtenir un diagnostic synthétique de la dette documentaire à l’échelle d’un projet complet, avec quelques statistiques,mais ce résumé ne peut remplacer le diagnostic détaillé, la priorisation et la liste des corrections à mener symbole par symbole, entre autres, qui sont les livrables de notre offre Audit.
Pour rattraper une dette documentaire importante, CI Fix n’est généralement pas adapté : cet outil est pensé pour corriger progressivement, pas pour générer massivement des docstrings sur des centaines de symboles. Si vous avez besoin de supprimer une dette documentaire importante afin de partir sur de bonnes bases pour la maintenance incrémentale, demandez-nous un devis pour la génération des docstrings via l’offre Build.

Bien sûr ! Les besoins diffèrent grandement d’un projet à l’autre, aussi l’offre Build est conçue pour s’adapter à toutes les demandes, que ce soit la simple génération ou correction des docstrings d’un projet, la création d’un package documentaire complet, ou tout niveau intermédiaire de granularité.

Les plans standard couvrent l’utilisation autonome de CI Check et les plans CI Fix avec leurs quotas mensuels. L’offre Enterprise ajoute des limites de crédits personnalisées, l’intégration dans d’autres environnements CI, la configuration sur mesure ainsi qu’un accompagnement d’intégration et de support. Elle élargit donc principalement le périmètre d’intégration et de service, sans changer le principe des contrôles ni des validations.

Par défaut, CI Check fonctionne en diff-first et contrôle les fichiers Python et les symboles affectés par la range Git. Le mode catchup permet toutefois d’analyser un dépôt entier : avec --check-mode catchup --git-diff ${EMPTY_TREE}..HEAD, où ${EMPTY_TREE} désigne l’arbre Git vide, tous les fichiers Python suivis par Git sont considérés comme ajoutés et contrôlés. Le résumé produit est alors représentatif de l’ensemble du dépôt pour cette exécution. Ce mode reste un rapport Check et ne remplace pas les livrables détaillés de l’offre Audit.

Oui, selon la configuration choisie. Une erreur produit un code de sortie d’échec. Le traitement des warnings dépend de fail_on_warning. Les sévérités peuvent être configurées par code DMT, ainsi que les visibilités, les types de symboles, le mode de contrôle et la politique appliquée lorsqu’une base Git est indisponible.

Non. CI Check analyse statiquement les fichiers Python, leurs signatures et leurs docstrings. Il n’importe pas votre application, ne l’exécute pas et ne lance pas vos tests. Il exécute uniquement les commandes Git nécessaires à la résolution du diff et de la base. Les tests du projet restent sous la responsabilité de votre propre CI.

Une range passée explicitement avec --git-diff est prioritaire. Sinon, sur une pull request, Check utilise l’ancêtre commun avec la branche de base. Sur un push linéaire, il utilise GITHUB_BEFORE_SHA..GITHUB_SHA lorsque l’ancien SHA est bien un ancêtre du nouveau. Après un force-push, un rebase, un amend ou un squash, il utilise d’abord une branche de référence configurée, puis le dernier ancêtre commun disponible. Si aucune base fiable n’existe, la configuration choisit entre l’échec, l’analyse partielle du dernier commit ou un résultat inconclusif non bloquant. La stratégie, la complétude et la raison sont indiquées dans le rapport JSON.

Le workflow Check de référence utilise uniquement contents: read. Il n’a besoin ni d’écrire dans le dépôt, ni de clé LLM, ni de clé Gateway. Le workflow Fix qui pousse une correction nécessite contents: write pour créer et pousser une branche de correction. Il utilise également un jeton de distribution Fix, une clé API Gateway et le secret du fournisseur LLM sélectionné, par exemple OPENROUTER_API_KEY. Un contexte OIDC nécessite en plus id-token: write : il est requis pour certains usages OSS ou certains reruns, mais pas pour le mode paid standard avec clé API seule.

CI Fix lit le rapport Check, sélectionne les diagnostics qu’il sait corriger, génère les docstrings nécessaires et valide chaque candidat avec le vérificateur déterministe ainsi qu’avec la gate de sécurité du rendu. Par défaut, la CLI applique les patches et crée un commit. --dry-run prévisualise les corrections, --no-commit applique les patches sans commit et --push pousse le commit vers l’upstream. Un workflow peut choisir de créer au préalable une branche dédiée, comme docmethis-fix/..., afin de soumettre les corrections à revue.

Le quota commercial correspond aux crédits mensuels du plan et aux éventuels packs. Chaque demande réserve atomiquement le nombre de crédits calculé par Fix. Cette demande ne doit pas dépasser le hard cap technique configurable du Gateway, indépendant du plan. Un dépassement du hard cap produit REQUEST_INVALID, tandis qu’un quota insuffisant produit QUOTA_EXHAUSTED. En cas d’échec complet ou partiel de la correction, la réservation est libérée ; en cas de succès complet, elle est consommée. CI Check reste indépendant du quota CI Fix.

DocMeThis est tout à fait compatible avec l’analyse de bases de code confidentielles. Selon le niveau de sensibilité, l’analyse peut être réalisée via cloud souverain, runner auto-hébergé, intervention sur site, voire environnement strictement air-gapped. L’Audit repose sur une analyse statique : l’application n’a pas besoin d’être exécutée. DocMeThis ne conserve jamais le code fourni par le client.

Pas nécessairement. Les offres CI Check et CI Fix fonctionnent dans votre environnement, et CI Fix s’appuie sur votre propre fournisseur de LLM. Le code ne transite donc pas par nos serveurs. Quant aux offres Audit et Build, nous pouvons également les exécuter depuis votre infrastructure, selon le niveau de confidentialité nécessaire.
Dans tous les cas, nous ne conservons jamais le code qui nous est confié, et nous n’utilisons jamais les données pour un autre objectif que la création des livrables souscris par le client.

Étant donné leur mode d’action, la surface d’exploitation de nos services semble relativement faible en termes de risques. Quoi qu’il en soit, nous faisons notre possible pour suivre les meilleures pratiques en termes de cybersécurité, et une revue externe de sécurité est sur notre feuille de route.

La gestion des abonnements et de la facturation est assurée par Chargebee. Selon le moyen de paiement choisi, les données de paiement sont ensuite traitées par Stripe ou PayPal via le checkout Chargebee. DocMeThis ne stocke aucune information bancaire sur ses propres serveurs.

La gestion des abonnements, de la facturation et des quotas est assurée par Chargebee, prestataire spécialisé dans la facturation. DocMeThis limite au maximum la conservation de données client sur ses propres serveurs : nous ne conservons que les informations nécessaires au fonctionnement du service, comme l’identification du compte, les droits d’accès, les informations techniques indispensables et les éléments nécessaires au support client.

CI Check exécute son analyse dans votre runner et n’envoie pas votre code à DocMeThis ni à un service LLM. Il peut écrire localement un cache et des rapports, que votre workflow peut ensuite conserver comme artefacts. CI Fix transmet les prompts et le contexte nécessaires au fournisseur LLM configuré dans votre projet. Pour du code confidentiel, l’utilisation d’un fournisseur local ou auto-hébergé est fortement recommandée. Les règles de conservation et d’utilisation des données dépendent du fournisseur LLM choisi. Gateway ne reçoit pas le manifeste du code : ni fichiers, ni symboles, ni chemins, ni hash de code.

Ce sont deux notions différentes.

L’inférence d’un LLM repose sur des calculs probabilistes, et n’est donc généralement pas reproductible. La génération est dite déterministe lorsque, pour une même entrée, le modèle produit la même sortie. Certains moteurs d’inférence permettent aujourd’hui, pour certains modèles, de garantir ce déterminisme.

À noter : les fournisseurs de modèles ne sont généralement pas configurés pour proposer cette fonctionnalité. C’est pourquoi notre offre CI Fix n’est pas présentée comme déterministe à ce jour. Seule l’offre Build peut l’être, lorsque nous avons la maîtrise du moteur d’inférence et de sa configuration.

La génération est contrainte lorsque l’espace de génération du modèle est volontairement limité : prompt précis, contexte issu de l’AST, format de sortie restreint, validation et rejet des sorties non conformes, etc.

Ces contraintes ne rendent pas le modèle infaillible, mais elles réduisent fortement le risque d’hallucination et permettent de détecter, rejeter ou corriger les sorties qui ne respectent pas les faits observables dans le code.

Non, seule l’offre Build inclut l’inférence : à ce jour notre infrastructure ne permet pas de fournir un service d’inférence en continu. Le service CI Fix étudie le contexte AST, génère un prompt dédié à chaque élément à documenter, lance la requête LLM, et vérifie la validité de la docstring générée. Il ne consomme donc pas directement les tokens, l’inférence est déléguée au modèle de votre choix, à configurer dans GitHub ou GitLab. Ce système autorise une grande flexibilité : vous pouvez utiliser votre forfait Claude ou ChatGPT, déployer votre propre modèle, ou passer par une API tierce. Nous conseillons l’utilisation d’un modèle léger avec de bonnes performances en développement.

L’audit documentaire et la détection de dérive reposent sur de l’analyse statique, sans génération IA. Pour les offres de génération de docstrings, les modalités d’utilisation de l’IA dépendent du niveau de confidentialité choisi.

DocMeThis peut utiliser à peu près n’importe quel modèle d’IA générative. Pour la génération documentaire intégrée à la CI, vous pouvez donc choisir le modèle de votre choix. Pour la génération documentaire premium, plus lourde à traiter, nous avons testé et sélectionné plusieurs modèles avec lesquels nous avons l’habitude de travailler, mais le choix final du modèle vous appartiendra.

Oui. DocMeThis ne dépend pas d’un fournisseur IA en particulier, mais a été pensé et conçu pour pouvoir se brancher à n’importe quel fournisseur, ou presque. Que vous souhaitiez utiliser votre abonnement Claude d’Anthropic ou ChatGPT d’OpenAI, ou une API de votre choix, ou encore un modèle déployé localement, tout est possible, ou presque.

Le runtime actuel du package CI Check requiert Python 3.12 ou supérieur. Cette contrainte concerne l’exécution de Check, pas nécessairement la version de Python ciblée par le dépôt analysé : du code Python 3.x plus ancien peut être analysé lorsqu’il reste compatible avec le parseur et les dépendances utilisés. Le périmètre actuel couvre les fichiers .py, .pyw et .pyi, ainsi que les docstrings au format NumPy. La prise en charge d’autres langages et d’autres styles, notamment Google et reStructuredText/Sphinx, fait partie de nos priorités de développement.