Rafiq IA Lab

IA-12 — IA pour documentation technique, procédures, DAT, DEX et rapports

---

1. Titre du module

IA-12 — IA pour documentation technique, procédures, DAT, DEX et rapports

Partie 3 — IA appliquée au travail IT

---

2. Objectif pédagogique

À la fin de ce module, l'apprenant doit être capable de :

• utiliser l'IA pour rédiger plus vite et mieux une documentation technique ;
• transformer des notes brutes ou un brouillon en procédure claire ;
• rédiger un DEX, un DAT, une fiche d'intervention, un compte rendu, une checklist ;
• documenter une installation, une restauration, une configuration réseau, une sauvegarde, un déploiement ;
• produire ces documents pour des contextes réels (GLPI, FOG, Nextcloud, Windows Server, Linux, DHCP/DNS, FortiGate, Docker, hébergement web) ;
• appliquer la structure d'une bonne documentation ;
• respecter les limites : vérifier commandes, chemins, versions, et ne pas inventer de détails.

Prérequis : Partie 2 (IA-07/08 prompts, IA-09 vérification) et IA-10/IA-11 (diagnostic et scripts, qui alimentent la documentation).

---

3. Niveau

Intermédiaire.

Module très opérationnel : la documentation est un livrable récurrent du métier IT. L'IA y apporte un gain de temps important, à condition de vérifier les éléments techniques.

---

4. Durée estimée

---

5. Résumé clair et simple

La documentation est souvent la tâche que les techniciens repoussent : chronophage, fastidieuse, jamais « finie ». C'est précisément là que l'IA est la plus utile. Elle excelle à structurer, reformuler et mettre en forme — exactement ce qui prend du temps quand on rédige une procédure ou un rapport.

Le principe de base : vous fournissez la matière (vos notes, vos commandes, ce que vous avez fait), l'IA produit un document structuré et lisible. Vous transformez ainsi un brouillon désordonné en procédure propre, un fil d'intervention en compte rendu, une suite de manipulations en documentation réutilisable.

Le métier IT utilise plusieurs types de documents : la procédure (comment faire, pas à pas), le DEX (dossier d'exploitation : comment exploiter/maintenir au quotidien), le DAT (dossier d'architecture technique : ce qui est en place et pourquoi), la fiche d'intervention, le compte rendu, la checklist. Chacun a sa structure, et l'IA peut produire un bon squelette pour chacun.

Mais une documentation IT contient des faits techniques : commandes, chemins, versions, adresses. Or l'IA peut en inventer (hallucinations, IA-04). La règle est donc claire : l'IA rédige et structure, vous vérifiez chaque élément technique. Une procédure fausse est plus dangereuse qu'une procédure absente, car elle sera suivie de confiance. Et la confidentialité s'applique : pas de secrets ni de données sensibles dans le document ni dans le prompt (IA-17).

---

6. Compétences visées

À l'issue de ce module, l'apprenant saura :

• produire rapidement des documents techniques structurés avec l'IA ;
• transformer des notes/brouillons/captures en procédures propres ;
• distinguer et rédiger procédure, DEX, DAT, fiche d'intervention, compte rendu, checklist ;
• documenter installation, restauration, configuration, sauvegarde, déploiement ;
• appliquer une structure de documentation claire et réutilisable ;
• vérifier les éléments techniques et éviter les inventions ;
• protéger les informations sensibles dans la documentation.

---

7. Notions clés à comprendre

• Documentation technique : ensemble de documents décrivant comment installer, configurer, exploiter ou dépanner un système.
• Procédure : suite d'étapes claires et reproductibles pour réaliser une tâche.
• DEX (Dossier d'EXploitation) : document décrivant comment exploiter et maintenir un service au quotidien (tâches récurrentes, surveillance, sauvegardes, contacts).
• DAT (Dossier d'Architecture Technique) : document décrivant l'architecture mise en place (composants, schéma, choix techniques, dépendances).
• Fiche d'intervention : trace d'une action réalisée (contexte, actions, résultat).
• Compte rendu : synthèse d'un événement ou d'une intervention.
• Checklist : liste de contrôle à cocher.
• Rollback (retour arrière) : procédure pour revenir à l'état précédent en cas de problème.
• Anonymisation : retrait des éléments sensibles avant rédaction/partage (IA-17).

---

8. Cours complet structuré

8.1 — Pourquoi l'IA est utile pour documenter

La documentation demande surtout de la structuration et de la reformulation : deux points forts des LLM. L'IA aide à :

• transformer des notes en désordre en document organisé ;
• uniformiser le style et le vocabulaire ;
• compléter un plan type (prérequis, étapes, vérifications) ;
• reformuler pour le bon niveau de lecteur ;
• gagner du temps sur la mise en forme.

Ce qu'elle ne fait pas : connaître votre infrastructure réelle, garantir l'exactitude des commandes, inventer des faits justes par hasard. La matière vient de vous ; la forme, de l'IA.

8.2 — Transformer des notes brutes (ou une capture) en procédure

C'est l'usage roi. Méthode :

1. Rassemblez votre matière : commandes tapées, étapes suivies, captures, messages.
2. Anonymisez (IP internes, identifiants, secrets — IA-17).
3. Demandez une mise en forme structurée :

« À partir de ces notes brutes : [coller], rédige une procédure : Objectif / Prérequis / Étapes numérotées / Commandes commentées / Vérification / Rollback. Signale les éléments à adapter et tes incertitudes. »

1. Vérifiez chaque commande, chemin et version (IA-09).

Pour une capture d'écran de texte, transcrivez l'essentiel : ne transmettez pas une image contenant des données sensibles.

8.3 — La structure d'une bonne documentation

Une documentation IT efficace contient généralement :

• Titre clair et version/date ;
• Objectif : à quoi sert ce document ;
• Périmètre : ce qui est couvert (et ce qui ne l'est pas) ;
• Prérequis : droits, accès, outils, sauvegardes ;
• Étapes numérotées : actions précises, dans l'ordre ;
• Commandes : commentées, prêtes à adapter ;
• Vérifications : comment confirmer que ça marche ;
• Rollback : comment revenir en arrière ;
• Points de vigilance : risques, pièges ;
• Contacts / références si utile.

Une bonne doc est reproductible : une autre personne doit pouvoir l'appliquer sans vous.

8.4 — Procédure, DEX, DAT : ne pas confondre

L'IA peut produire un bon squelette pour chacun ; vous le remplissez et le vérifiez avec vos données réelles.

8.5 — Documenter les tâches courantes

L'IA aide à documenter, à partir de votre matière :

• une installation (logiciel, service, serveur) ;
• une restauration (à partir d'une sauvegarde) ;
• une configuration réseau (VLAN, règles, adressage) ;
• une procédure de sauvegarde (quoi, quand, où, vérification) ;
• une procédure de déploiement (mise en production, rollback).

Pour chacune, exigez les sections Prérequis / Étapes / Vérification / Rollback / Vigilance.

8.6 — Exemples par environnement (matière fournie par vous)

L'IA peut structurer la documentation pour des contextes variés ; vous fournissez les détails réels :

• GLPI : procédure de création d'un ticket type, ou d'un champ personnalisé.
• FOG : procédure de capture/déploiement d'image (à vérifier selon votre version).
• Nextcloud : procédure d'installation ou de sauvegarde des données et de la base.
• Windows Server : procédure de création d'un partage avec droits.
• Linux : procédure d'installation et de durcissement de base d'un service.
• Sauvegarde/restauration : procédure complète avec test de restauration.
• DHCP/DNS : procédure de création d'une étendue ou d'une zone.
• FortiGate : procédure de création d'une règle (à vérifier dans la doc constructeur).
• Docker : procédure de déploiement d'un conteneur avec volume persistant.
• Hébergement web : procédure de mise en ligne avec HTTPS.

Pour les équipements spécifiques (FortiGate, FOG…), la syntaxe et les écrans varient selon les versions : vérifiez toujours dans la documentation officielle (l'IA peut inventer une option).

8.7 — Transformer une discussion en document propre

Après un échange exploratoire (avec l'IA ou un collègue), demandez une mise au propre :

« À partir de toute notre discussion, produis une procédure finale propre : titre, version, prérequis, étapes numérotées, commandes commentées, vérification, rollback, points de vigilance. Élimine les pistes abandonnées. Signale ce qui reste à confirmer. »

C'est le même réflexe qu'en IA-08, appliqué au livrable documentaire.

8.8 — Limites et vérifications spécifiques à la doc

La documentation est lue et appliquée. Une erreur s'y propage. Donc :

• vérifier les commandes (existence, options, version) ;
• vérifier les chemins (un chemin faux casse la procédure) ;
• vérifier les versions (une étape valable sur une version peut être fausse sur une autre) ;
• ne pas laisser l'IA inventer des détails techniques : si une info manque, vous la fournissez ou vous marquez « à compléter » plutôt que d'accepter une invention ;
• dater et versionner : une doc non datée devient vite trompeuse.

Astuce : demandez à l'IA de marquer entre crochets ce qui doit être renseigné par vous ([adresse du serveur], [version]) plutôt que de combler les trous par des suppositions.

---

9. Exemples concrets liés au monde IT

Pour chaque cas, l'IA structure ; vous fournissez les détails réels et vérifiez (anonymisez — IA-17).

1. Procédure d'installation Nextcloud. À partir de vos commandes, l'IA produit Objectif/Prérequis/Étapes/Vérification/Rollback. Vous vérifiez chemins et versions.
2. Procédure de sauvegarde/restauration. L'IA structure la doc et insiste sur le test de restauration ; vous validez sur un environnement de test.
3. Fiche d'intervention. Après un dépannage, vous dictez les faits, l'IA produit une fiche claire (contexte, actions, résultat, suites).
4. Compte rendu d'incident. À partir de notes, l'IA rédige une synthèse professionnelle ; vous vérifiez l'exactitude des faits.
5. DEX d'un service Linux. L'IA propose un squelette (tâches récurrentes, surveillance, sauvegardes, contacts) ; vous le remplissez.
6. DAT d'une petite infra. L'IA structure composants et dépendances à partir de votre description ; le schéma et les choix réels viennent de vous.
7. Procédure de déploiement Docker. L'IA rédige les étapes avec volume persistant et rollback ; vous vérifiez les commandes et l'image utilisée.
8. Checklist de mise en production web (HTTPS). L'IA génère une checklist ; vous l'adaptez à votre hébergement.

Constante : la matière technique vient de vous, la structure de l'IA, la vérification aussi de vous.

---

10. Cas pratique guidé

Objectif : transformer des notes brutes d'intervention en procédure propre et vérifiée.

Contexte. Vous venez d'installer et de configurer un partage de fichiers sur un Windows Server. Vous avez pris des notes en vrac pendant l'opération.

Étape 1 — Rassembler et anonymiser la matière. Regroupez vos notes : étapes suivies, chemins, droits attribués, vérifications faites. Retirez les noms réels, les identifiants et toute donnée sensible (IA-17).

Étape 2 — Demander une mise en forme structurée. Prompt : « Transforme ces notes en procédure réutilisable : Objectif / Périmètre / Prérequis / Étapes numérotées / Commandes ou actions / Vérification / Rollback / Points de vigilance. Marque entre crochets ce que je dois renseigner. Ne complète pas les informations manquantes par des suppositions. Notes : [coller]. »

Étape 3 — Vérifier les éléments techniques (IA-09). Relisez chaque étape : les chemins sont-ils corrects ? Les droits décrits correspondent-ils à ce que vous avez réellement fait ? Les commandes/écrans correspondent-ils à votre version de Windows Server ? Corrigez ce qui doit l'être.

Étape 4 — Compléter les crochets. Remplacez les [à renseigner] par les vraies valeurs (ou laissez-les comme champs si la procédure doit être générique).

Étape 5 — Dater, versionner, faire relire. Ajoutez titre, version et date. Idéalement, faites tester la procédure par un collègue : s'il y arrive sans vous, elle est bonne.

Résultat du cas pratique : une procédure propre, vérifiée, datée et reproductible, produite en une fraction du temps habituel.

---

11. Exercice pratique à faire seul

Consigne. Choisissez une tâche que vous savez faire (ex. installer un logiciel, configurer un partage, créer une sauvegarde). À partir de vos propres notes :

1. Rédigez le prompt demandant une procédure structurée (sections : Objectif / Prérequis / Étapes / Commandes / Vérification / Rollback / Vigilance), avec consigne de ne pas inventer et de marquer entre crochets ce qui manque.
2. Listez 3 éléments techniques que vous devrez vérifier (commande, chemin, version).
3. Ajoutez une section Rollback réaliste.
4. Indiquez 2 précautions de confidentialité.
5. Précisez où vous indiquerez la version et la date.

Contexte. Vous produisez une vraie procédure réutilisable de votre métier.

Résultat attendu. Le prompt + la procédure structurée vérifiée.

Critères de réussite :

• le prompt impose une structure claire et interdit les inventions ;
• les éléments techniques à vérifier sont identifiés ;
• une section Rollback est présente et réaliste ;
• les précautions de confidentialité sont concrètes ;
• la procédure est datée et versionnée.

---

12. Quiz de 10 questions QCM

Une seule bonne réponse par question.

Q1. Pour quel type de tâche l'IA est-elle particulièrement utile en documentation ?

• A. Connaître votre infrastructure réelle
• B. Structurer, reformuler et mettre en forme
• C. Garantir l'exactitude des commandes
• D. Inventer des faits justes

Q2. Que répond une procédure ?

• A. « Qu'est-ce qui est en place et pourquoi ? »
• B. « Comment faire cette tâche, pas à pas ? »
• C. « Que s'est-il passé ? »
• D. « Qui est responsable ? »

Q3. Que décrit un DAT ?

• A. L'architecture technique en place (composants, schéma, choix)
• B. La liste des tickets
• C. Le planning des congés
• D. Le budget annuel

Q4. Que décrit un DEX ?

• A. Le code source d'un logiciel
• B. Comment exploiter et maintenir un service au quotidien
• C. La maquette graphique
• D. Le contrat commercial

Q5. Quelle section est essentielle pour pouvoir revenir en arrière ?

• A. Le titre
• B. Le rollback (retour arrière)
• C. La police de caractères
• D. Le logo

Q6. Que faut-il vérifier en priorité dans une doc technique produite par IA ?

• A. La couleur du texte
• B. Les commandes, chemins et versions
• C. Le nombre de pages
• D. Rien

Q7. Quand une information manque, que vaut-il mieux faire ?

• A. Laisser l'IA combler par une supposition
• B. Marquer un champ [à renseigner] et le compléter soi-même
• C. Supprimer la section
• D. Publier quand même

Q8. Pourquoi dater et versionner une documentation ?

• A. Pour faire joli
• B. Parce qu'une doc non datée devient vite trompeuse
• C. Ce n'est pas utile
• D. Pour augmenter le nombre de pages

Q9. Avant de transmettre une capture ou des notes à l'IA, il faut :

• A. Ajouter des mots de passe
• B. Anonymiser (retirer IP internes, identifiants, secrets)
• C. Envoyer le fichier client complet
• D. Ne rien changer

Q10. Quel est le bon partage des rôles ?

• A. L'IA fournit la matière technique et la vérité
• B. Vous fournissez la matière et vérifiez ; l'IA structure et met en forme
• C. L'IA publie la doc directement
• D. Personne ne vérifie

---

13. Réponses corrigées du quiz avec explications

Q1 → B. L'IA excelle à structurer/reformuler/mettre en forme. Elle ne connaît pas votre infra (A), ne garantit pas l'exactitude (C) et n'invente pas de faits justes (D).

Q2 → B. Une procédure explique comment faire, pas à pas. A décrit un DAT, C un compte rendu, D est hors sujet.

Q3 → A. Le DAT décrit l'architecture en place et les choix. Les autres options sont hors sujet.

Q4 → B. Le DEX décrit l'exploitation/maintenance au quotidien. A, C et D sont faux.

Q5 → B. Le rollback permet de revenir à l'état précédent. Les autres éléments sont cosmétiques.

Q6 → B. On vérifie commandes, chemins et versions. A, C et D sont secondaires ou faux.

Q7 → B. On marque un champ à renseigner plutôt que d'accepter une invention. A est dangereux, C et D inadaptés.

Q8 → B. Une doc non datée devient trompeuse (versions qui évoluent). Les autres réponses sont fausses.

Q9 → B. On anonymise avant de transmettre. A, C et D exposent des données.

Q10 → B. Vous fournissez la matière et vérifiez ; l'IA structure. A, C et D sont faux ou dangereux.

Barème indicatif : 8/10 ou plus = notions acquises. 5 à 7 = relisez les sections 8.3 et 8.4. Moins de 5 = reprenez le cours et rejouez le cas pratique.

---

14. Flashcards de révision

Carte 1 Q : Sur quoi l'IA est-elle la plus utile en documentation ? R : Structurer, reformuler, mettre en forme.

Carte 2 Q : Que répond une procédure ? R : Comment faire une tâche, pas à pas (étapes, commandes, vérifications).

Carte 3 Q : Que décrit un DAT ? R : L'architecture technique en place : composants, schéma, choix, dépendances.

Carte 4 Q : Que décrit un DEX ? R : Comment exploiter et maintenir un service au quotidien.

Carte 5 Q : Sections clés d'une bonne procédure ? R : Objectif / Prérequis / Étapes / Commandes / Vérification / Rollback / Vigilance.

Carte 6 Q : À quoi sert la section Rollback ? R : À revenir à l'état précédent en cas de problème.

Carte 7 Q : Que vérifier en priorité dans une doc produite par IA ? R : Les commandes, les chemins et les versions.

Carte 8 Q : Que faire quand une info manque ? R : Marquer [à renseigner] et compléter soi-même, sans laisser l'IA inventer.

Carte 9 Q : Pourquoi dater et versionner ? R : Une doc non datée devient vite trompeuse.

Carte 10 Q : Avant de transmettre des notes/captures à l'IA ? R : Anonymiser (IP internes, identifiants, secrets).

Carte 11 Q : Test ultime d'une bonne procédure ? R : Un collègue l'applique avec succès sans votre aide.

Carte 12 Q : Partage des rôles IA / vous ? R : Vous : matière + vérification ; l'IA : structure et mise en forme.

---

15. Erreurs fréquentes

• Laisser l'IA inventer des commandes, chemins ou détails techniques.
• Ne pas vérifier les versions : une étape valable ailleurs peut être fausse chez vous.
• Oublier le rollback et les points de vigilance.
• Documentation non datée / non versionnée → vite trompeuse.
• Transmettre des données sensibles (captures non anonymisées, identifiants).
• Confondre les types de documents (procédure ≠ DAT ≠ DEX).
• Produire une doc non testée : personne ne l'a appliquée pour vérifier qu'elle marche.
• Trop de jargon ou un niveau inadapté au lecteur.

---

16. Bonnes pratiques

• Fournir la matière (notes, commandes, contexte) ; laisser l'IA structurer.
• Imposer une structure claire (Objectif / Prérequis / Étapes / Vérification / Rollback / Vigilance).
• Interdire les inventions : champs [à renseigner] plutôt que suppositions.
• Vérifier commandes, chemins, versions (IA-09) ; recouper avec la doc officielle pour les équipements spécifiques.
• Dater et versionner chaque document.
• Faire tester la procédure par quelqu'un d'autre.
• Anonymiser systématiquement (IA-17).
• Adapter le niveau au lecteur visé.

---

17. Point vigilance : limites, risques, sécurité et vérification humaine

Bloc obligatoire à lire attentivement.

Ce qu'il faut vérifier :

• chaque commande, chemin et version mentionnés ;
• la correspondance avec votre environnement réel (écrans, options) ;
• l'absence d'invention : tout détail technique douteux est à confirmer ;
• la présence d'une date et d'une version.

Ce qu'il ne faut pas faire :

• diffuser une procédure non vérifiée ni testée ;
• laisser l'IA combler les trous par des suppositions ;
• inclure des secrets ou des données sensibles dans le document ou le prompt.

Risques de mauvaise utilisation :

• une procédure fausse suivie de confiance peut causer un incident ;
• des détails inventés (chemins, options) cassent l'opération ;
• une doc périmée induit en erreur.

Risques de confidentialité :

• la documentation contient souvent des informations internes sensibles (adresses, schémas, identifiants) ;
• gestion des données sensibles et RGPD : module IA-17.

Limites de l'IA en documentation :

• elle ne connaît pas votre infrastructure réelle ;
• elle peut inventer des éléments techniques (IA-04) ;
• elle ne sait pas si une procédure « marche » : seul le test le dit.

Cas où une validation humaine est indispensable :

• toute procédure destinée à être appliquée en production ;
• toute documentation de sécurité, de sauvegarde ou de restauration ;
• tout document officiel ou destiné à un client.

Principe à retenir : l'IA rédige et structure ; vous fournissez les faits, vérifiez et testez. Une procédure se valide en la faisant appliquer par quelqu'un d'autre.

---

18. Mini-projet de fin de module

Titre : « Mon dossier de documentation type »

Objectif. Constituer un petit ensemble documentaire cohérent autour d'une tâche IT réelle : une procédure, une fiche d'intervention, et une checklist — produits avec l'IA, vérifiés et testés.

Contexte. Vous standardisez votre documentation. Tout repose sur votre matière réelle (anonymisée). Aucun environnement de production n'est touché.

Prérequis. Avoir lu le cours (section 8) ; maîtriser la vérification (IA-09).

Étapes :

1. Choisir une tâche que vous maîtrisez (ex. installer/sauvegarder un service).
2. Rédiger une procédure complète avec l'IA (structure imposée), à partir de vos notes, sans inventions, avec champs [à renseigner].
3. Produire une fiche d'intervention type pour cette tâche.
4. Produire une checklist de contrôle associée.
5. Vérifier tous les éléments techniques (commandes, chemins, versions) et dater/versionner les documents.
6. Faire tester la procédure par une autre personne (ou la rejouer vous-même en lab) et corriger.

Résultat attendu. Un mini-dossier : 1 procédure + 1 fiche d'intervention + 1 checklist, vérifiés et datés.

Critères de réussite :

• structure claire et cohérente pour chaque document ;
• aucun détail technique inventé (champs [à renseigner] sinon) ;
• éléments techniques vérifiés ;
• documents datés et versionnés ;
• procédure testée (par un tiers ou en lab) ;
• aucune donnée sensible.

Amélioration possible. Transformez la procédure en DEX : ajoutez les tâches récurrentes, la surveillance, les sauvegardes et les contacts. Vous passez de « comment installer » à « comment exploiter au quotidien ».

---

19. Ressources gratuites recommandées

Ne recommander que des ressources gratuites ou accessibles gratuitement. Toute ressource dont la gratuité ou la disponibilité n'est pas certaine est signalée par la mention « À vérifier avant publication. »

• Documentation officielle des outils cités (GLPI, Nextcloud, Docker docs.docker.com, doc Windows Server sur Microsoft Learn, doc FortiGate sur le site Fortinet, doc FOG) — sources de référence pour vérifier commandes, écrans et versions. À vérifier avant publication (liens et versions évoluent).
• Markdown — langage de balisage simple pour rédiger une documentation lisible et réutilisable (titres, listes, tableaux, blocs de code). De nombreux guides gratuits existent. À vérifier avant publication (choisir un guide fiable).
• Versions gratuites des assistants (ChatGPT, Claude, Gemini, Mistral) — pour transformer notes en procédures sur des cas anonymisés. À vérifier avant publication (offres variables).
• « Objectif IA » (OpenClassrooms) — openclassrooms.com/fr/courses/6417031-objectif-ia-initiez-vous-a-l-intelligence-artificielle — pour le cadre général de l'IA. (Gratuit, vérifié ; compte gratuit possible.)

Remarque : la doc officielle reste la référence pour vérifier les éléments techniques. Ce module ne promet aucune certification.

---

20. Résumé final du module

• La documentation est chronophage : c'est là que l'IA aide le plus, car elle structure et reformule très bien.
• Principe : vous fournissez la matière (notes, commandes, contexte), l'IA produit un document clair et structuré.
• Types de documents à distinguer : procédure (comment faire), DEX (exploiter au quotidien), DAT (architecture en place), fiche d'intervention, compte rendu, checklist.
• Structure d'une bonne doc : Objectif / Périmètre / Prérequis / Étapes / Commandes / Vérification / Rollback / Vigilance, datée et versionnée.
• Applicable à de nombreux contextes : GLPI, FOG, Nextcloud, Windows Server, Linux, DHCP/DNS, FortiGate, Docker, hébergement web.
• Limite essentielle : l'IA peut inventer des commandes/chemins/versions. On vérifie tout, on interdit les inventions (champs [à renseigner]), on teste la procédure, et on anonymise (IA-17). Une procédure fausse est plus dangereuse qu'une procédure absente.

---

21. Validation demandée avant le module suivant

Validation demandée avant le module suivant

Souhaites-tu que je passe au module suivant ou que je corrige/améliore ce module d'abord ?

(Module suivant prévu : IA-13 — IA pour automatiser son travail avec n8n, Telegram, mail et webhooks.)