Ce document est le point d'entrée du dépôt. Il se lit seul, sans avoir besoin d'ouvrir les autres fichiers : il pose le cadre (pourquoi, pour qui, sous quelle forme), détaille les méthodes de collecte à mettre en œuvre, et justifie les choix de formalisme. Les autres fichiers du dépôt en sont l'application détaillée (méthodologie pas à pas, modèle à remplir, boîte à outils, exemple traité) — voir §6.
Une veille n'est pas une recherche documentaire. Une recherche documentaire répond une fois à une question posée à un instant donné ; une veille est un dispositif — un processus outillé, reproductible et traçable — qui continue de produire de l'information utile après sa mise en place, y compris si la personne qui l'a montée n'est plus là pour l'actionner.
Deux raisons la justifient ici :
- Une raison de fond. Le sujet traité — quel cadre d'analyse de risques adopter pour un SI intégrant du big data et de l'IA — évolue vite et sur plusieurs strates à la fois : les normes (rythme quasi stable, révisions à 5 ans), les référentiels d'agences publiques (mis à jour sans préavis), la réglementation européenne (calendrier qui bouge au trimestre). Une réponse figée à un instant T devient fausse en quelques mois si personne ne la réalimente.
- Une raison de méthode. Une veille produit une décision documentée, pas un état de l'art. Chaque information captée est évaluée, datée, tracée jusqu'à sa source primaire, puis convertie en recommandation argumentée pour un destinataire identifié. C'est ce qui distingue un dossier de veille d'une simple synthèse bibliographique.
Une veille sans destinataire identifié n'est pas exploitable. Ce dépôt en vise quatre, avec des attentes différentes :
| Destinataire | Ce qu'il attend | Registre |
|---|---|---|
| DSI / décideur | Une option claire, un coût, un risque de ne rien faire | Décisionnel, 1 page |
| Équipe data / IA | Ce qui change concrètement dans le travail quotidien | Opérationnel, 2-3 pages |
| DPO / juridique | Les obligations réglementaires identifiées et datées | Réglementaire |
| Client interne ou externe | Une vulgarisation compréhensible sans expertise technique | Vulgarisé |
Écrire pour soi — c'est-à-dire produire un document qui ne s'adresse à aucun de ces profils en particulier — est l'erreur la plus fréquente : le contenu devient un résumé de lecture, pas un outil d'aide à la décision.
La forme se décline en trois niveaux, qui coexistent :
- Le dispositif de collecte lui-même — flux configurés, alertes posées, journal de veille tenu à jour. Il n'a pas de forme figée : c'est un ensemble d'outils connectés (voir §4).
- Le dossier de veille, document unique de 20 à 30 pages hors annexes, structuré en neuf sections (cadrage, dispositif de collecte, corpus évalué, synthèse par thème, diagnostic, recommandations, plan de partage, bibliographie, annexes). C'est le livrable de fond.
- Les restitutions différenciées, une par destinataire du §2 : note de synthèse (1 page), fiche technique (2-3 pages), support de restitution orale (10-12 diapositives). C'est ce qui rend la veille réellement partagée, pas seulement produite.
Toute méthode de collecte relève de l'une de ces deux logiques. Un dispositif de veille solide combine systématiquement les deux : le push seul rate ce qui n'a pas de flux, le pull seul ne passe pas à l'échelle.
Une fois configurée, la source pousse l'information sans action répétée de votre part.
| Canal | Principe | Exemples de sources | Outil pour l'actionner |
|---|---|---|---|
| Flux RSS/Atom | Le site publie un flux structuré, l'agrégateur le relève automatiquement | ANSSI, CNIL, ENISA, NIST | FreshRSS (libre, auto-hébergé), Inoreader, Feedly, Thunderbird |
| Alerte par requête | Un service surveille une requête ou un texte et notifie par e-mail | EUR-Lex (alerte sur un règlement), arXiv (alerte par catégorie), Google Alerts | Compte sur le service, création de l'alerte |
| Newsletter | Abonnement à une lettre d'information éditoriale | LeMagIT, CLUSIF | Inscription directe ; noter l'éditeur et son modèle économique |
| Suivi de page | Détection de changement sur une page sans flux natif | Dossier législatif d'un texte, page d'un référentiel | changedetection.io (libre, auto-hébergeable) |
Mise en œuvre. Pour un flux RSS : repérer l'icône ou le lien « flux »/« RSS » sur le site source, copier son URL, l'ajouter dans l'agrégateur choisi, fixer une fréquence de relevé. Pour une alerte : créer un compte sur le service, poser l'alerte sur un mot-clé, un texte ou une catégorie précis (pas une requête trop large, qui produit du bruit). Pour un suivi de page : indiquer l'URL exacte à surveiller et le seuil de sensibilité au changement.
Aucun flux ne vous prévient : la collecte dépend d'une action périodique et volontaire.
| Canal | Principe | Exemples | Outil pour l'actionner |
|---|---|---|---|
| Consultation manuelle périodique | Visite régulière d'une page sans flux disponible | Pages institutionnelles statiques | Calendrier de relance à fréquence fixe |
| Recherche ciblée | Interrogation directe d'une base ou d'un moteur sur une question précise | Légifrance, catalogue ISO | Requêtes documentées (mots-clés FR/EN, opérateurs) |
| Veille sociale | Suivi manuel de comptes d'experts identifiés | Profils LinkedIn/Mastodon nommés | Parcours périodique, pas d'abonnement automatisé fiable |
| Interrogation de corpus | Question posée à l'ensemble des sources déjà rassemblées | Corpus personnel | NotebookLM (n'interroge que vos propres sources) |
Mise en œuvre. Fixer une fréquence explicite (hebdomadaire, bimensuelle) et une liste fermée de pages ou de comptes à consulter à chaque passage — sans liste fermée, la veille pull dérive vers une navigation non documentée, invérifiable a posteriori.
Que le canal soit push ou pull, il doit être documenté au moment de sa mise en place : outil utilisé, requête ou URL exacte, fréquence, date de mise en service, puis alimenté par un journal de veille daté (date, canal, source, information captée, décision : retenu / écarté / à surveiller). C'est cette traçabilité, et non le volume collecté, qui distingue un dispositif de veille d'une accumulation de liens.
| Choix | Formalisme retenu | Pourquoi |
|---|---|---|
| Documents de travail de ce dépôt | Markdown, fins de ligne LF (.gitattributes en place) |
Texte brut versionnable sous Git : diff lisible, indépendant d'un éditeur propriétaire, portable entre postes. Rend nativement les diagrammes Mermaid utilisés pour les schémas (architecture de collecte, articulation des référentiels, calendrier, matrice de priorisation) sans outil externe. |
| Journal de veille | Table à colonnes fixes (date, canal, source, information, décision) | Format identique quel que soit le canal, push ou pull : permet le tri et le filtrage, et se recopie tel quel en annexe du dossier final. |
| Grille d'évaluation des sources | Notation chiffrée 1 à 3 sur six critères, total sur 18 | Un formalisme quantifié rend les arbitrages comparables et vérifiables par un tiers, là où une appréciation qualitative libre ne le permet pas. |
| Bibliographie | Gestionnaire bibliographique (Zotero) | Un formalisme de citation normalisé (auteur, titre, éditeur, date, URL, date de consultation) généré automatiquement supprime la source d'erreur la plus fréquente en fin de parcours. |
| Dossier final remis | ODT ou PDF, 20 à 30 pages, sommaire généré automatiquement | Ce n'est pas un choix mais une exigence du référentiel de certification : un document paginé et structuré, pas un format texte brut. Le Markdown de ce dépôt sert de brouillon structuré et versionné ; l'export vers ODT/PDF (LibreOffice, pandoc) intervient une fois le contenu stabilisé, pas avant. |
| Fichier | Rôle |
|---|---|
| 1-guide-apprenant-methodologie-veille.md | Méthode détaillée en six étapes, critères d'évaluation, planning, auto-évaluation |
| 2-modele-dossier-veille.md | Modèle vierge du dossier final à compléter, section par section |
| 3-outils-et-ressources.md | Sources primaires, outillage push/pull concret, kit de démarrage |
| 4-dossier-veille.md | Exemple de dossier traité de bout en bout sur le sujet imposé |