1. Une IA transforme la mascotte d'un site en personnage imaginaire
Un petit site publiait de nombreux articles à l'aide de l'IA. Certains comparaient des personnalités à celles de personnages de Chiikawa, notamment Hachiware. Interrogée sur la mascotte du site, une autre IA a proposé qu'il s'agisse d'un prétendu « Hachiware compliqué » appartenant à cette série.
Pardon, mais qui est-ce ?
La mascotte originale venait d'être recrutée dans l'œuvre de quelqu'un d'autre. Sans candidature ni entretien. L'IA avait signé le contrat toute seule.
Le seul fait établi est que cette réponse a été donnée. Impossible de savoir si l'IA avait réellement lu les articles, associé deux noms ou tout inventé. Rien ne prouve ici que ce personnage existe dans l'œuvre officielle. Une réponse prononcée avec assurance n'est pas une information vérifiée.
2. Pendant ce temps, l'usine à articles travaille sans relâche
Le processus rédige, simplifie le texte, prépare douze versions linguistiques complètes, vérifie, publie et diffuse des liens. Quand une étape échoue, une autre cherche la cause, propose une réparation et recommence les vérifications.
Les comptes rendus deviennent un feuilleton.
IA A : « Le problème de publication est corrigé. »
IA B : « Tous les contrôles sont passés. »
IA C : « J'ai trouvé une nouvelle cause d'arrêt. »
Superviseur : « Affectons un autre réparateur. »
Lecteur : « Le rapport va finir plus long que les articles. »
Cette scène fait rire, mais enregistrer une correction ne prouve pas que la page publique fonctionne. Une fabrique de contenu est aussi parfois un atelier de dépannage.
3. « Près de 1 900 articles ? » Encore faut-il savoir ce qui est compté
Le mot « article » peut cacher au moins cinq catégories :
- Textes originaux : contenus indépendants.
- Pages par langue : traductions d'un même texte.
- Textes prêts mais non publiés : encore en attente de contrôle ou de mise en ligne.
- Pages publiées : réellement accessibles aux lecteurs.
- Chemins du site : pouvant comprendre menus, applications et pages hors articles.
Ainsi, 1 000 textes originaux publiés dans douze langues peuvent produire jusqu'à 12 000 pages localisées. Cela ne fait pas 12 000 idées originales.
Un relevé de fonctionnement faisait apparaître 15 862 chemins. Ce n'était pas le nombre d'articles originaux japonais. Toute affirmation du type « il y a 1 900 articles » exige une date, une unité et un statut de publication. Sans cela, les chiffres gonflent et leur sens s'évapore.
4. Le dépôt GitHub atteignait environ 2,46 Go
Dans un exemple anonymisé, GitHub indiquait 2 400 972 Kio, soit environ 2,29 Gio ou 2,46 Go en unités décimales, le 8 octobre 2026.
« Pourtant, un article, ce n'est que du texte ! »
Un dépôt peut aussi contenir du code, des traductions, des listes de publication, des résultats de vérification, des images, de l'audio et l'historique des modifications. Cependant, le total ne permet pas d'attribuer une taille à chaque catégorie. Il faut une analyse distincte. La taille indiquée par GitHub ne correspond pas nécessairement à celle d'un dossier local.
Article : « Je fais quelques kilo-octets. »
Historique : « J'ai gardé tes anciennes versions. »
Traductions : « Nous sommes douze à arriver. »
Entrepôt : « Qui a autorisé ce groupe ? »
5. Réponse : GitHub Free ne signifie pas « 5 Go au total, puis facture »
Pour les dépôts Git ordinaires, GitHub ne fixe pas un unique volume gratuit total en gigaoctets qui déclencherait automatiquement une facture. La barre des 5 Go est une recommandation de taille, pas un seuil de facturation.
La documentation juge idéal de rester sous 1 Go et recommande vivement de rester sous 5 Go. Une autre page conseille un maximum de 10 Go sur disque pour les données Git compressées. Ce n'est pas non plus une garantie de disposer gratuitement de 10 Go.
Si un dépôt perturbe excessivement l'infrastructure, GitHub peut demander une correction. « Au-delà de 5 Go, on paie » est donc faux, tout comme « gratuit veut dire entrepôt infini ».
6. Les véritables limites ne concernent pas le même stockage
| Ressource | Limite ou volume compris |
|---|---|
| Dépôt Git ordinaire | Pas de seuil de facturation global unique ; idéal sous 1 Go, vivement recommandé sous 5 Go |
| Données Git sur disque | Maximum recommandé de 10 Go, sans rapport avec un passage automatique au payant |
| Fichier ordinaire individuel | Avertissement au-delà de 50 Mio, blocage au-delà de 100 Mio ; ajout dans le navigateur jusqu'à 25 Mio |
| Envoi unique de modifications | Limite de 2 Gio |
| Git LFS pour gros fichiers | GitHub Free comprend 10 Gio de stockage et 10 Gio de transfert, séparément du Git normal |
| Résultats de GitHub Actions | GitHub Free comprend 500 Mo de stockage pour ces résultats et généralement 2 000 minutes de calcul par mois |
Ce ne sont pas les mêmes quotas. Les dépassements de LFS, Actions et des autres services sont gérés selon leurs règles de facturation et les budgets fixés. Un dépôt de 2,46 Go n'a pas consommé automatiquement les 500 Mo des résultats Actions. Et rester sous 5 Go dans Git ne garantit pas que les autres quotas suffisent.
7. Pourquoi le dépôt grossit parfois plus vite que le nombre d'articles
Git conserve les fichiers actuels, mais aussi leurs changements. Un gros index réécrit toutes les heures peut rester un seul fichier visible dans la dernière version, alors que les anciennes versions demeurent dans l'historique. Révisions, nouvelles traductions, journaux de contrôle et résultats enregistrés plusieurs fois peuvent faire croître le dépôt indépendamment du nombre de nouveaux articles.
Git compresse toutefois les données et stocke efficacement les versions proches. Une modification ne double pas automatiquement la taille. Il faut mesurer pour identifier les véritables responsables.
Il est pertinent de garder dans Git les textes sources et le code dont on veut suivre les changements. Les fichiers générés fréquemment et les médias volumineux peuvent, selon les besoins, être placés ailleurs.
8. Les conflits d'écriture peuvent arriver avant le manque d'espace
Si plusieurs agents IA modifient presque simultanément un fichier partagé, leurs changements peuvent entrer en conflit. Une réparation réussit tandis qu'un autre traitement lit un ancien index de publication. L'article est prêt, mais le site affiche toujours l'ancienne version.
Tout attribuer à « GitHub est plein » ferait manquer la vraie cause. La taille des fichiers, la fréquence des mises à jour, les écritures concurrentes et la cohérence de publication sont des sujets distincts.
Quatre vérifications suffisent à structurer l'enquête : le dernier texte existe-t-il ? A-t-il été validé ? A-t-il été déployé ? La page publique affiche-t-elle exactement cette nouvelle version ? On applaudira le rapport « réparé » après la quatrième réponse.
9. Quatre gestes pour préserver le fonctionnement gratuit
Mesurer avant d'effacer. Examiner les gros fichiers et l'historique, pas uniquement le chiffre total. GitHub cite aussi git-sizer parmi les outils d'analyse.
Ranger les résultats jetables ailleurs. Des index constamment régénérés, des journaux temporaires, des images ou des sons n'ont pas toujours besoin d'être conservés éternellement dans Git.
Limiter les réécritures inutiles. Une petite modification sans rapport ne devrait pas reconstruire un énorme index. Après un conflit, relire l'état courant et vérifier le résultat réel.
Ne pas réécrire l'historique à la légère. Supprimer un fichier de la dernière version peut le laisser dans les anciens changements. Réécrire un historique partagé peut casser des références et des copies : il faut sauvegarder et évaluer les conséquences.
10. La quantité compte moins que ce que les lecteurs reçoivent
Des milliers d'originaux et des dizaines de milliers de pages traduites ne garantissent pas le public. Les pages sont-elles trouvables ? Exactes ? Naturelles dans chaque langue ? Apportent-elles quelque chose de neuf ?
Les recommandations publiques de Google privilégient les contenus utiles, originaux et conçus pour les personnes. Elles mettent aussi en garde contre la production massive de pages sans valeur, principalement destinées à manipuler les résultats de recherche. Ce n'est pas l'usage de l'IA en soi qui pose problème, mais la multiplication de contenus sans utilité réelle.
Quant au prétendu « Hachiware compliqué », l'histoire rappelle qu'une invention amusante de l'IA reste une invention tant qu'elle n'est pas vérifiée.
Usine : « Je vais multiplier les articles. »
GitHub : « Je conserverai plus d'historique. »
Contrôleur : « Je réduirai les erreurs. »
IA de recherche : « Je vais multiplier les personnages ! »
Tout le monde : « Pas cette multiplication-là ! »
En bref : 5 Go ne constituent pas le péage de GitHub Free. Capacité, mise en ligne, qualité et affirmations de l'IA demandent des vérifications différentes. La vraie réussite, c'est l'information fiable qui arrive jusqu'aux lecteurs, pas le nombre de fichiers stockés.
