academic-humanizer : une passe d'édition pour les brouillons académiques assistés par IA
Strip AI-writing tells from papers and grant proposals (NSF/NIH), while keeping scholarly voice and tying claims to evidence. A skill for Claude Code, Codex, and MorphMind.
En bref
- De quoi s’agit-il ?
- Ce skill édite les articles et propositions de bourse rédigés avec l'aide d'un LLM : il retire les tics d'écriture IA, rattache les affirmations aux preuves et conserve la voix de l'auteur. Sa portée est volontairement étroite, et c'est là son intérêt comme sa limite.
- À qui s’adresse-t-il ?
- Adoptez academic-humanizer si vous rédigez déjà des articles ou des propositions NSF/NIH avec l'aide d'un LLM et que vous voulez une relecture qui ne touche ni vos chiffres ni vos citations. Passez votre chemin si vous cherchez un outil pour contourner un détecteur d'IA, ou si vous ne disposez d'aucun texte de référence dans votre propre voix : la calibration n'a alors rien sur quoi s'appuyer.
- Puis-je l’utiliser commercialement ?
- À vérifier. La licence de ce dépôt n’entre pas dans les catégories que nous classons automatiquement : lisez son fichier LICENSE avant tout usage commercial.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 75 jours.
- En quel langage est-il écrit ?
- GitHub n’indique pas de langage principal pour ce dépôt.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : un brouillon IA qui a perdu la précision du chercheur
Le point de départ est décrit sans détour dans le README : une équipe qui écrit beaucoup d'articles et de propositions a commencé à utiliser l'IA pour ses brouillons, et le résultat est générique et verbeux. Les symptômes cités sont précis : ouvertures en « In recent years... », formulations gonflées, phrases trop longues. S'y ajoutent deux dérives plus coûteuses pour un chercheur : le texte s'éloigne de la voix de l'auteur, et il perd la précision dont dépend le travail scientifique.
Le constat sur les outils existants est le vrai argument du projet. Les humanizers du marché visent les blogs et le marketing. Passés sur un article ou une proposition NSF, ils aplatissent la précision en même temps que le reste, et le README est catégorique : le vocabulaire soigneusement choisi dont dépend l'écriture académique est la première chose à disparaître. Le public visé est donc étroit : des chercheurs qui ont déjà un brouillon assisté par IA, un historique de travaux acceptés ou financés, et une exigence de fidélité aux chiffres et aux références.
Ce que la passe d'édition préserve, et pourquoi c'est le cœur du sujet
La promesse centrale tient en une phrase du README : les nombres, citations et affirmations restent exactement tels qu'ils ont été écrits. Concrètement, le skill laisse tranquilles le hedging adossé à des preuves, la voix passive là où elle convient, le « we », les définitions et les symboles. Il ne modifie ni un chiffre ni une référence.
Ce qui est retiré relève d'une liste nommée : « paves the way », « extensive experiments », « to the best of our knowledge », « In recent years... », les mots delve, underscore, tapestry, les triades, les phrases très longues, les tirets cadratins. Le second mécanisme est plus intéressant : aucune affirmation ne doit être plus forte que les données. Le README donne l'exemple d'un passage de « prove » à « show empirically », et indique que les magnitudes vagues deviennent des intervalles attribués. C'est une règle de rédaction scientifique, pas de style. Elle suppose que l'auteur accepte de voir ses tournures les plus assurées rabotées.
Six couches, un mode bourse, et une calibration sur vos propres textes
L'architecture est décrite comme une séquence de six couches : catalogue général des tics d'IA, tics propres à l'académique, préservation des conventions savantes, appariement affirmation/preuve, calibration voix et lieu de publication, puis mode proposition de financement. La boucle audit puis réécriture est définie dans SKILL.md, que le dépôt ne fournit pas ici : impossible de dire à quoi ressemblent les règles exactes, seulement qu'elles existent et qu'elles constituent le cœur de l'outil.
La sixième couche mérite qu'on s'y arrête. Elle distille ce que le README appelle la structure stable des propositions NSF et NIH, avec deux principes : préserver la vision qu'un article couperait, et concentrer l'effort sur les premières pages, puisque c'est ce que les évaluateurs notent. Le projet précise lui-même que les exigences contraignantes (limites de pages, format, échéances) ne sont pas couvertes et renvoie au PAPPG de la NSF et au guide de candidature du NIH. C'est une honnêteté appréciable : la couche 6 est une heuristique de rédaction, pas une conformité réglementaire.
La calibration est le point le plus personnel. Le README raconte que l'équipe a fait comparer par l'IA ses propres brouillons avec ses articles acceptés et ses propositions financées, puis a trié les différences à la main. Et il invite explicitement à forker : les règles reflètent la voix d'un groupe, il faut les adapter aux siennes en pointant l'outil vers quelques articles passés.
Installation et invocation
L'installation tient en une commande, qui place le dépôt dans le répertoire des skills de Claude Code :
git clone https://github.com/AIScientists-Dev/academic-humanizer ~/.claude/skills/academic-humanizer
Le README indique qu'il s'agit d'un simple SKILL.md accompagné d'exemples, ce qui permet de l'utiliser aussi comme skill ou comme prompt système pour Codex et MorphMind, en pointant l'agent vers SKILL.md. L'invocation se fait par /academic-humanizer, avec un extrait de texte collé ou un chemin de fichier, par exemple main.tex. Deux paramètres optionnels sont mentionnés : correspondre à la voix d'un article antérieur, avec prior_paper.pdf, et préciser la revue visée, l'exemple donné étant ICLR.
Rien dans le matériel ne décrit de dépendance, de fichier de configuration ou de clé à renseigner. C'est un artefact textuel : la valeur se trouve dans les règles de SKILL.md, pas dans un moteur.
Là où l'outil ne vous aidera pas
Le README pose lui-même la limite la plus importante : ce n'est pas un outil pour échapper à la détection d'IA, et il ne dispense pas de déclarer l'assistance. Si c'est ce que vous cherchez, le projet dit non. Il précise aussi qu'il ne génère pas de résultats, n'invente pas de données et ne modifie pas les citations.
Deux réserves tiennent au matériel fourni. D'abord, le champ licence du dépôt affiche NOASSERTION alors que le README et le badge indiquent MIT : le fichier LICENSE tranchera, mais l'écart entre les deux signaux est réel. Ensuite, la calibration sur la voix dépend d'un prérequis que tout le monde n'a pas : il faut disposer d'articles acceptés ou de propositions financées à donner en référence. Un doctorant en début de parcours n'a rien à fournir, et la couche 5 se réduit alors à des règles génériques. Sur un texte où la précision prime sur la fluidité, par exemple une section de méthodes truffée de symboles, la passe n'apporte pas grand-chose : le README annonce que les définitions et les symboles sont laissés intacts, donc l'essentiel du texte reste tel quel.
Face à un humanizer généraliste ou à un pipeline de recherche complet
Le README nomme lui-même deux projets voisins, et la comparaison est instructive. blader/humanizer, sous MIT, vise les tics d'écriture IA dans les textes de blog, occasionnels et encyclopédiques. academic-humanizer réutilise son catalogue général comme couche 1 et l'étend à la prose scientifique. La différence n'est pas la couverture des tics, c'est la couche 3 : préserver les conventions savantes, et la couche 4, rattacher chaque affirmation à une preuve. Un humanizer de blog n'a aucune raison de distinguer « prove » de « show empirically » ; c'est précisément ce qui casse un article passé entre ses mains.
koaeraser/ARMS est d'une autre nature : un pipeline autonome pour les articles de statistique et de méthodologie, de l'idée au manuscrit révisé. academic-humanizer se présente comme la pièce plus étroite, une passe d'édition unique. Le choix est clair : ARMS fait le travail en amont, academic-humanizer intervient sur un brouillon qui existe déjà et ne produit rien de neuf.
Ce qu'il faut vérifier avant de forker
Le coût de maintenance est faible sur le papier : pas de dépendance, pas de build, pas de version publiée à suivre (le dépôt n'a aucune release). Le README affiche la version 0.3.2 dans un badge, ce qui suggère un projet encore en mouvement, et le dernier push est daté. Le coût réel est ailleurs : chaque évolution de votre voix ou de votre domaine suppose de retoucher les règles vous-même, puisque le projet assume d'être personnalisé plutôt que passe-partout.
Sur la licence, le README déclare MIT et le dépôt affiche NOASSERTION. Si vous forkez et redistribuez, lisez le fichier LICENSE avant de vous appuyer sur l'une ou l'autre mention ; ce n'est pas un conseil juridique, juste la vérification minimale. Reste un point que le matériel ne permet pas de trancher : sans SKILL.md sous les yeux, on ne peut pas juger la qualité des règles ni leur ordre d'application. C'est le premier fichier à ouvrir.
Conclusion éditoriale
Adoptez academic-humanizer si vous rédigez déjà des articles ou des propositions NSF/NIH avec l'aide d'un LLM et que vous voulez une relecture qui ne touche ni vos chiffres ni vos citations. Passez votre chemin si vous cherchez un outil pour contourner un détecteur d'IA, ou si vous ne disposez d'aucun texte de référence dans votre propre voix : la calibration n'a alors rien sur quoi s'appuyer. Avant de vous engager, vérifiez deux choses : le contenu réel de SKILL.md, puisque c'est là que vivent les règles, et la politique de divulgation de la revue ou de l'agence visée, car l'outil ne vous en dispense pas.
Notes de la communauté