Automatiser ses rapports PDF avec l’IA sans erreurs de calcul

Que signifie automatiser des rapports PDF avec l’IA ?

Pour automatiser des rapports PDF avec l’IA, répartissez chaque rapport en trois tâches et confiez chacune à l’outil qui l’exécute de manière fiable : le code calcule les chiffres, un LLM rédige les commentaires et un modèle met en page le document. Les projets qui échouent confient ces trois tâches au modèle.

Le reste de ce guide construit ce pipeline en Python autour d’un rapport mensuel des ventes. Remplacez les données par les vôtres : la structure restera la même.

Pourquoi le LLM ne doit produire ni le PDF ni les chiffres

Demander à un modèle de créer un PDF fonctionne dans une démonstration, mais dérive en production. Il existe trois approches courantes, et chacune échoue à un endroit différent.

La question décisive est de savoir qui est responsable en cas de chiffre erroné. Si la réponse est « vous », le chiffre doit provenir d’un code que vous pouvez tester, et non d’un modèle qui échantillonne du texte. Un rapport récurrent doit également avoir le même aspect en mars qu’en février : seul un modèle fixe peut le garantir.

Le pipeline : le code calcule, le LLM rédige et un modèle génère le PDF

Une architecture fiable comporte six étapes. Une seule fait appel à un modèle.

1. Extraire. Récupérez les données brutes depuis une base de données, un fichier CSV ou une API.
2. Calculer les faits. Agrégez les données dans le code au sein d’un dictionnaire facts. Il constitue l’unique source des chiffres du rapport.
3. Rédiger le texte. Envoyez les faits au LLM et récupérez un JSON conforme à un schéma.
4. Vérifier. Confirmez que chaque chiffre du texte existe dans les faits. Bloquez la production si ce n’est pas le cas.
5. Générer. Remplissez un modèle HTML et convertissez-le en PDF. Les graphiques sont dessinés par le code, jamais par le modèle.
6. Livrer. Stockez le PDF avec ses faits et son texte, puis envoyez-le ou conservez-le en attente d’approbation.

Étape 1 : calculer les faits dans le code

Le dictionnaire de faits constitue le contrat entre vos données et tous les éléments en aval. Construisez-le avec du code classique testé et gardez-le concis : il ne doit contenir que les chiffres que le rapport est autorisé à mentionner.

import pandas as pd

def build_facts(csv_path: str, month: str) -> dict:
    df = pd.read_csv(csv_path, parse_dates=["order_date"])
    period = df["order_date"].dt.to_period("M")
    cur = df[period == pd.Period(month)]
    prev = df[period == pd.Period(month) - 1]

    revenue = round(float(cur["amount"].sum()), 2)
    prev_revenue = round(float(prev["amount"].sum()), 2)
    change_pct = (
        round((revenue - prev_revenue) / prev_revenue * 100, 1)
        if prev_revenue else None      # None, never 0, when there is no baseline
    )
    top = cur.groupby("channel")["amount"].sum().nlargest(3)

    return {
        "month": month,
        "orders": int(len(cur)),
        "revenue": revenue,
        "prev_revenue": prev_revenue,
        "revenue_change_pct": change_pct,
        "top_channels": [
            {"name": name, "revenue": round(float(v), 2)} for name, v in top.items()
        ],
    }

Deux habitudes sont essentielles. Renvoyez None lorsqu’une valeur ne peut pas être calculée : zéro ressemble à un résultat réel et le modèle se fera un plaisir de le commenter. Arrondissez une seule fois, dans cette fonction, afin que le texte et le tableau du PDF ne puissent jamais diverger.

Étape 2 : encadrer le texte avec un schéma JSON

Demandez au modèle de remplir des champs, pas de produire un document. Chaque champ est un emplacement que le modèle positionne ; le modèle ne peut donc rien déplacer, ajouter ou modifier sur la page. Une sortie contrainte par schéma est l’outil adapté : selon la documentation Structured Outputs d’OpenAI, la réponse respecte votre JSON Schema au lieu d’être simplement un JSON valide, et les refus deviennent détectables dans le code. Si vous utilisez un autre fournisseur, recherchez son mode de sortie contraint par schéma : le principe reste identique.

import json
from openai import OpenAI
from pydantic import BaseModel

client = OpenAI()
MODEL = "your-validated-model"   # pin the model you tested; re-test before changing it

class ReportNarrative(BaseModel):
    headline: str
    summary: str
    channel_notes: list[str]
    risks: list[str]

SYSTEM = (
    "You write the commentary for a monthly sales report. "
    "Use ONLY numbers that appear in the facts JSON, copied exactly. "
    "Never calculate, round or estimate. If a value is null, say it is unavailable. "
    "Do not claim trends, causes or records that the facts do not show."
)

def write_narrative(facts: dict) -> ReportNarrative:
    response = client.responses.parse(
        model=MODEL,
        input=[
            {"role": "system", "content": SYSTEM},
            {"role": "user", "content": json.dumps(facts)},
        ],
        text_format=ReportNarrative,
    )
    if response.output_parsed is None:   # refusal or incomplete output
        raise RuntimeError("No valid narrative returned")
    return response.output_parsed

N’oubliez pas ce que le schéma ne garantit pas. Il garantit la structure, pas la véracité : une chaîne parfaitement valide peut tout de même contenir un chiffre inventé par le modèle. C’est la raison d’être de l’étape suivante. Envoyez également des faits agrégés, et non des lignes brutes concernant vos clients. Le modèle n’a besoin que des chiffres qu’il va décrire, et transmettre moins de données est le moyen le plus simple de limiter les risques liés à la confidentialité.

Étape 3 : vérifier chaque chiffre avant l’envoi du PDF

C’est l’étape que la plupart des tutoriels ignorent, alors qu’elle rend le pipeline suffisamment sûr pour fonctionner sans surveillance. Extrayez tous les chiffres du texte généré et exigez que chacun apparaisse dans les faits. Si ce n’est pas le cas, déclenchez une erreur et ne livrez rien.

import re

NUM = re.compile(r"\d[\d,]*\.?\d*")

def to_float(token: str) -> float:
    return float(token.replace(",", "").rstrip("."))

def fact_numbers(obj) -> set[float]:
    nums: set[float] = set()
    if isinstance(obj, dict):
        for v in obj.values():
            nums |= fact_numbers(v)
    elif isinstance(obj, list):
        for v in obj:
            nums |= fact_numbers(v)
    elif isinstance(obj, str):
        nums |= {to_float(m) for m in NUM.findall(obj)}   # catches "2026-09" style periods
    elif isinstance(obj, (int, float)) and not isinstance(obj, bool):
        nums.add(float(obj))
    return nums

def check_narrative(facts: dict, n) -> None:
    allowed = fact_numbers(facts)
    text = " ".join([n.headline, n.summary, *n.channel_notes, *n.risks])
    unknown = [m for m in NUM.findall(text)
               if not any(abs(to_float(m) - a) < 0.01 for a in allowed)]
    if unknown:
        raise ValueError(f"Numbers not found in facts: {unknown}")

Une fois ce contrôle en place, toute l’exécution tient en quatre lignes :

facts = build_facts("orders.csv", "2026-09")
narrative = write_narrative(facts)
check_narrative(facts, narrative)          # raises, so nothing ships
render_pdf(facts, narrative, "reports/sales-2026-09.pdf")

Le contrôle est volontairement strict. Un modèle qui écrit 12 % alors que le fait indique 12,4 est rejeté, tout comme un nombre isolé tel que le 3 de « top 3 channels », sauf si vous ajoutez les petits ordinaux à une liste blanche. Renforcez le prompt avant d’assouplir le contrôle. Les chiffres ne sont pas le seul enjeu : ajoutez au prompt une instruction qui interdit d’affirmer des causes, des tendances ou des records que les faits ne contiennent pas, et lisez vous-même les premiers textes générés.

Durant les premières semaines d’un nouveau rapport, mettez le PDF en attente d’une validation humaine et n’activez l’envoi automatique qu’après une période suffisamment longue de contrôles réussis. Conservez les textes rejetés : ils vous montreront quelle instruction du prompt n’est pas respectée.

Étape 4 : générer le PDF à partir d’un modèle

Rédigez le rapport sous la forme d’un modèle HTML classique et laissez un moteur de rendu le convertir en PDF. WeasyPrint constitue une bonne solution par défaut pour les documents professionnels, car il prend en charge le CSS d’impression. Sa documentation officielle pour la version 70.0 indique que Python 3.10 ou une version ultérieure et Pango 1.44 ou une version ultérieure sont requis. Elle recommande également une installation avec pip, puis l’exécution de weasyprint --info pour vérifier que les bibliothèques système sont détectées.

Le modèle contient la mise en page et les champs du texte viennent s’y insérer :

<h1>{{ n.headline }}</h1>
<p class="lead">{{ n.summary }}</p>
<table>
  {% for c in facts.top_channels %}
  <tr><td>{{ c.name }}</td><td>{{ "{:,.2f}".format(c.revenue) }}</td></tr>
  {% endfor %}
</table>

Le format de page, les marges et les numéros de page se définissent avec du CSS classique :

@page {
  size: A4;
  margin: 18mm;
  @bottom-center { content: "Page " counter(page) " of " counter(pages); }
}

Effectuez ensuite le rendu. L’échappement automatique de Jinja est activé : le texte du modèle est donc inséré comme une donnée et jamais interprété comme du balisage :

from pathlib import Path
from urllib.parse import unquote, urlparse

from jinja2 import Environment, FileSystemLoader, select_autoescape
from weasyprint import HTML
from weasyprint.urls import URLFetcher

TEMPLATES = Path("templates").resolve()
env = Environment(loader=FileSystemLoader(TEMPLATES), autoescape=select_autoescape(["html"]))

class AssetsOnlyFetcher(URLFetcher):
    # Local files are allowed only inside the templates folder
    def fetch(self, url, headers=None):
        if url.startswith("file:"):
            path = Path(unquote(urlparse(url).path)).resolve()
            if not path.is_relative_to(TEMPLATES):
                raise ValueError(f"Blocked local file: {url}")
        return super().fetch(url, headers)

def render_pdf(facts: dict, narrative, out_path: str) -> None:
    page = env.get_template("monthly_report.html").render(facts=facts, n=narrative)
    HTML(string=page, base_url=str(TEMPLATES), url_fetcher=AssetsOnlyFetcher()).write_pdf(out_path)

Trois points de la documentation méritent d’être pris en compte dès la conception :

• Polices. Si une police est absente, le PDF peut afficher des carrés ou aucun caractère à la place des lettres. Le problème apparaît d’abord avec les caractères accentués ou les alphabets non latins. Installez les polices sur le serveur ou référencez-les avec @font-face. Si vous chargez cette feuille CSS via un objet CSS, transmettez également une FontConfiguration, comme l’indique la documentation.
• Sécurité. La documentation avertit que du HTML ou du CSS non fiable peut lire des fichiers locaux et les intégrer à la sortie. Traitez le contenu du modèle comme une donnée non fiable : ne le laissez jamais générer du HTML brut, gardez l’auto-échapppement activé et limitez l’accès aux fichiers comme dans le fetcher ci-dessus. WeasyPrint intercepte les erreurs du fetcher et les transforme en avertissements : un fichier bloqué est ignoré au lieu de faire échouer l’exécution. Le fetcher sous forme de classe présenté ici correspond à la documentation de la version 70.0 ; les versions plus anciennes utilisaient une fonction simple.
• Vitesse. La documentation indique que le rendu peut être lent pour les documents longs et recommande des processus persistants pour traiter de nombreux documents, afin de ne payer le coût du démarrage qu’une seule fois. Un worker qui reste actif est préférable au lancement d’un nouveau processus pour chaque PDF.

Dessinez les graphiques dans le code avec matplotlib ou SVG et intégrez-les sous forme d’images. Le modèle décrit le graphique ; il ne le dessine jamais.

Quelle bibliothèque Python doit générer le PDF ?

Choisissez le moteur de rendu selon trois critères : la manière dont vous souhaitez décrire la mise en page, votre besoin éventuel de graphiques JavaScript et ce que vous êtes prêt à installer et à utiliser sous licence pour des projets clients. Vérifiez la licence actuelle de la version exacte utilisée avant de la mettre en production pour un client.

Pour la plupart des rapports professionnels récurrents, WeasyPrint associé à un modèle Jinja est le chemin le plus court entre l’idée et un pipeline facile à maintenir. Passez à Chromium uniquement lorsque vous avez réellement besoin de JavaScript pour générer la page.

Comment planifier et distribuer des rapports PDF automatisés

Une fois qu’une exécution fonctionne, le travail restant est essentiellement opérationnel. Voici les décisions qui permettent de conserver un rapport planifié fiable :

• Déclenchement. Utilisez le planificateur que vous exploitez déjà : cron sur un serveur, ordonnanceur cloud, workflow CI planifié ou file de tâches. Le pipeline est une simple fonction Python et n’en dépend pas.
• Idempotence. Identifiez chaque fichier par le type de rapport et la période, afin qu’une nouvelle exécution remplace le fichier au lieu d’en créer un doublon.
• Piste d’audit. Enregistrez ensemble les faits, le texte, la version du modèle et le PDF final. Si quelqu’un remet un chiffre en question, vous pourrez montrer précisément son origine.
• Gestion des erreurs. Si l’étape de vérification échoue, alertez une personne et conservez le dernier PDF valide à disposition. N’envoyez jamais un rapport que vous n’avez pas pu vérifier.
• Distribution. Envoyez un lien par e-mail pour les fichiers volumineux et une pièce jointe pour les petits fichiers, puis consignez le destinataire de chaque version.

L’appel au modèle se limite à une requête par rapport : le coût de fonctionnement le plus important est donc généralement le temps de validation humaine, et non l’utilisation de l’API. Ajustez le niveau de contrôle humain plutôt que la longueur du prompt. Si vous préférez confier cette réalisation à une équipe qui l’adaptera à vos sources de données et à vos modèles, Netalith crée des agents de reporting IA qui produisent des fichiers PDF, DOCX, Excel et PowerPoint.

Quand l’automatisation d’un rapport PDF n’en vaut pas la peine

L’automatisation entraîne un coût fixe : le modèle, le code des faits, les contrôles et la supervision. Elle ne vaut pas la peine dans les cas suivants :

• Le rapport est produit quelques fois par an. Concevoir le modèle prend plus de temps que les heures économisées.
• Chaque destinataire a besoin d’une structure différente et il n’existe aucun socle commun à utiliser comme modèle.
• La valeur du rapport repose sur un jugement professionnel, comme un avis juridique ou une conclusion d’audit. L’IA peut rédiger autour de ce jugement, mais la partie que vous vendez réellement n’est pas celle qui est automatisée.
• Les données sources ne sont pas fiables. L’automatisation publie plus rapidement des données erronées et leur donne une meilleure présentation : commencez par corriger les données.

Si vos rapports sont récurrents, structurés et construits à partir de données que vous pouvez interroger, le pipeline ci-dessus sera rapidement rentabilisé. Si vous souhaitez faire relire la conception par un spécialiste, envoyez à Netalith une description de votre rapport actuel pour obtenir un devis gratuit.