Discipline : Management de projet et agilité hybride

Coordination entre talents humains et outils d’automatisation via méthodes agiles adaptées à l’incertitude et à la transmission des savoirs.
agilité hybride, documentation vivante, portabilité des compétences, GitHub Copilot, formation transmissible

  • n8n

    n8n est une plateforme d’automatisation de flux de travail (workflow automation) open source et auto-hébergeable.

    Elle permet aux utilisateurs de connecter et d’interconnecter une multitude d’applications, services et API via une interface visuelle basée sur des nœuds (node-based).

    Son caractère open source confère un contrôle total des données et offre une alternative flexible aux solutions propriétaires.

    En gestion de projet, n8n est utilisé pour connecter des outils hétérogènes (CRM, bases de données, outils de communication, plateformes de tickets, etc.) et automatiser les tâches répétitives (notifications, mises à jour de statut, rapports d’avancement, synchronisation des jalons).

    Il permet au Chef de Projet de maintenir l’efficacité de son équipe et le contrôle des données.

    N8n.io

  • AI Product Manager

    Architecte de systèmes intelligents, pas magicien de l’algorithme.

    Idées reçues fréquentes

    Il « fait de l’IA » en intégrant des APIs de chatbot ou en activant un modèle pré-entraîné, comme on installe une appli.

    Cette vision réductrice confond automatisation et intelligence utile, et occulte les enjeux éthiques, techniques et humains qui structurent réellement le rôle.

    Ses missions

    L’AI Product Manager définit la stratégie d’un produit intégrant de l’intelligence artificielle, en identifiant des cas d’usage où l’IA apporte une réelle valeur sans surtechniciser l’inutile.

    Il travaille en étroite collaboration avec les data scientists, ingénieurs ML et équipes métier pour traduire des besoins utilisateurs en exigences techniques exploitables, tout en veillant à la qualité des données, à la justesse des métriques (précision, équité, latence) et à la gouvernance éthique.

    Il pilote le prototypage, les itérations de modèle, le déploiement et le monitoring en production, en documentant les limites, les biais potentiels et les conditions d’usage responsable.

    Le sens du métier

    Donner à l’intelligence artificielle une finalité humaine, transparente et contrôlable et non en faire un outil d’opacité, de discrimination ou d’automatisation aveugle. Il s’agit de concevoir des systèmes qui aident, plutôt que de décider à la place.

    Champ d’action

    • Identifier les cas d’usage pertinents pour l’IA (et dire non aux autres)
    • Définir la stratégie produit alignée sur les capacités techniques, les objectifs métier et les cadres éthiques (ex. : AI Act)
    • Gérer le backlog produit : données, features, métriques de performance, cycles d’entraînement
    • Prototyper avec des modèles open source, des APIs ou des outils low-code
    • Superviser la gouvernance : documentation des biais, explicabilité, droits des utilisateurs
    • Communiquer les capacités et les limites de l’IA aux parties prenantes non techniques
    • Piloter le monitoring post-déploiement : dérive du modèle, feedback utilisateurs, conformité

    Outils et terrains

    Jira, Trello, Figma, Whimsical, Weights & Biases, MLflow, Hugging Face, LangChain, Postman, Google Cloud AI Platform, Azure ML
    (ou alternatives éthiques/auto-hébergées : DVC, MLflow en local, modèles open locaux via LM Studio ou Ollama — avec précaution)

    Confusions fréquentes

    Pas un Data Scientist : il ne construit pas les modèles, mais définit ce qu’ils doivent résoudre.

    Pas un Tech Lead : il ne code pas l’infrastructure, mais en comprend les contraintes.

    Pas un Product Owner classique : il gère non seulement des features, mais des incertitudes, des données vivantes et des risques éthiques.

    Rémunération indicative (France, brut annuel)

    – Junior (0–3 ans) : 45 000 € – 60 000 €
    – Confirmé·e (3–6 ans) : 65 000 € – 85 000 €
    – Senior / Lead (6+ ans) : 90 000 € – 120 000 €+
    (Les écosystèmes scale-up, fonds d’IA ou grands groupes peuvent proposer des rémunérations plus élevées, parfois avec parts de equity.)

    Où le rencontrer ?

    Startups d’IA responsable, directions produit de grands groupes engagés dans la transformation éthique, laboratoires de recherche appliquée, éditeurs de logiciels critiques (santé, éducation, justice), collectifs de tech souveraine, structures publiques innovantes.

    Autres appellations

    AI Product Owner, ML Product Manager, Technical Product Manager (IA/ML), Responsible AI Product Lead

  • CALMS Code

    CALMS est un cadre de référence utilisé pour évaluer et guider la transformation DevOps au sein des organisations. Il résume les cinq dimensions essentielles à cultiver pour briser les silos entre les équipes de développement (Dev) et d’exploitation (Ops), et instaurer une démarche continue d’amélioration, de fiabilité et de collaboration.

    L’acronyme signifie :

    S – Sharing (Partage)
    → Encourager le partage transparent des connaissances, des outils, des retours d’expérience et des responsabilités.
    → Cela inclut la documentation vivante, les revues de code, les post-mortems sans blâme, et les communautés de pratique — en phase avec vos engagements autour de la résilience documentaire et de la transmission.

    C – Culture
    → Favoriser une culture de confiance, de responsabilité partagée et de collaboration transverse, plutôt qu’une logique de blâme ou de silos fonctionnels.

    A – Automation (Automatisation)
    Automatiser les tâches répétitives (intégration, tests, déploiement, surveillance) pour réduire les erreurs humaines, accélérer les livraisons et libérer du temps pour l’innovation.
    → En cohérence avec votre vision : « automatiser pour servir la logique humaine, pas remplacer la pensée ».

    L – Lean
    → Appliquer les principes Lean (élimination des gaspillages, flux continu, valeur client) aux processus techniques :

    Éviter la surproduction de fonctionnalités inutiles

    Réduire les temps d’attente (ex. : validations manuelles)

    Optimiser la sobriété des infrastructures (en lien avec l’éco-conception numérique)

    M – Measurement (Mesure)
    → Piloter par les données objectives :

    Temps de déploiement (Deployment Frequency)

    Taux d’échec des changements (Change Failure Rate)

    Temps de récupération (Mean Time To Recovery – MTTR)
    → Ces métriques permettent de mesurer la maturité DevOps et d’orienter les priorités.

    Synonymes / termes associés

    • Cadre CALMS
    • Pilier DevOps
    • Transformation DevOps
    • Culture DevOps
  • PRINCE2

    PRINCE2 est une méthodologie standardisée de gestion de projet, initialement développée par le gouvernement britannique.

    • Lancée en 1989 sous le nom de PRINCE (dans le cadre du projet Central Computer and Telecommunications Agency),
    • Puis révisée et généralisée en 1996 sous le nom de PRINCE2, afin de la rendre applicable à tout type de projet, au-delà du seul secteur informatique.

    Aujourd’hui, PRINCE2 est utilisée mondialement, notamment dans les secteurs publics, de la défense, des infrastructures critiques et des grands projets réglementés.

    Précision importante :
    Contrairement à ce que suggère parfois une lecture rapide, PRINCE2 n’est pas intrinsèquement adaptée aux projets numériques modernes (web, logiciels évolutifs, produits UX/UI).

    Elle excelle dans les environnements stables, bien définis et fortement encadrés, mais peut être trop rigide pour les projets où les besoins changent rapidement.

    C’est pourquoi une extension PRINCE2 Agile® a été publiée en 2015, combinant la gouvernance de PRINCE2 avec les pratiques flexibles de Scrum, Kanban, etc.

    Fondements de PRINCE2

    PRINCE2 repose sur sept principes, sept thèmes et sept processus. Vos « approches » correspondent en réalité à ces piliers, mais voici une reformulation alignée sur la terminologie officielle :

    Sept principes (non négociables)

    1. Justification commerciale continue
    2. Apprentissage de l’expérience
    3. Rôles et responsabilités clairement définis
    4. Gestion par étapes
    5. Gestion par exception (délégation avec seuils de tolérance)
    6. Focus sur les produits (livrables tangibles)
    7. Adaptation au contexte du projet (Tailoring)

    Sept processus (cycle de vie du projet)

    CodeNom (FR/EN)Objectif principal
    SUDémarrage d’un projet / Starting up a ProjectValider la faisabilité, nommer le chef de projet, créer le dossier initial
    DPDirection du projet / Directing a ProjectSupervision stratégique par le Project Board (sponsor, utilisateur, fournisseur)
    IPInitialisation du projet / Initiating a ProjectProduire le Plan de Projet, la Stratégie Qualité, le Registre des Risques, etc.
    CSContrôle d’une étape / Controlling a StagePilotage opérationnel par le chef de projet pendant l’exécution
    MPGestion de la livraison de produits / Managing Product DeliveryInterface entre l’équipe de réalisation et le chef de projet (livraison, qualité, conformité)
    SBGestion de la limite d’étape / Managing a Stage BoundaryBilan de l’étape, mise à jour des plans, demande d’autorisation pour l’étape suivante
    CPClôture de projet / Closing a ProjectConfirmation des livrables, archivage, retour d’expérience, libération des ressources

    Pourquoi PRINCE2 ? Quand l’utiliser ?

    Idéal pour :

    • Projets avec exigences stables dès le départ
    • Environnements réglementés ou soumis à audit
    • Besoin de traçabilité forte et de documentation structurée
    • Collaboration entre multiples parties prenantes avec rôles formels

    Moins adapté à :

    • Projets de produit digital itératif (ex. : plateforme culturelle en évolution continue)
    • Contextes où l’expérimentation UX, les retours utilisateurs rapides ou les pivots fréquents sont centraux
    • Équipes petites ou autonomes cherchant légèreté et rapidité
  • Design System

    Un design system est un cadre vivant, collaboratif et évolutif qui regroupe, documente et met à disposition les principes, les composants, les directives et les ressources nécessaires à la création d’interfaces utilisateur cohérentes, accessibles et efficaces à travers tous les produits, canaux ou équipes d’une organisation.

    Il ne se limite pas à un kit graphique ou une bibliothèque de composants : c’est un système de décision visuelle et expérientielle, qui permet aux designers, développeurs, rédacteurs et product managers de parler le même langage, de réduire la dette visuelle, et de garantir une expérience utilisateur homogène même sur des projets complexes ou distribués.

    Il repose sur trois piliers :

    1. Les principes : valeurs fondatrices (ex. : sobriété, accessibilité, résilience), choix typographiques, palette de couleurs, système de grille, hiérarchie visuelle.
    2. Les composants : éléments réutilisables (boutons, formulaires, modales, cartes, navigation…) avec leurs états (normal, hover, disabled, error).
    3. Les guidelines : règles d’usage, cas d’application, bonnes pratiques, exemples concrets, anti-patterns à éviter.

    Ce qu’il inclut généralement

    CatégorieExemples
    Design TokensCouleurs, espacements, polices, ombres, transitions
    Composants UIBouton, champ de formulaire, card, menu déroulant, modal
    Patterns UXNavigation, recherche, feedback utilisateur, validation de formulaire
    Ressources visuellesIcônes, illustrations, images de référence, animations
    DocumentationGuide d’utilisation, cas d’usage, exemples de code, accessibilité (WCAG)
    Outils d’intégrationBibliothèques React/Vue/Svelte, plugins Figma, Storybook, Zeplin

    Ressources design system

    Design system for Figma

    Open design Systems

    Designsystemsrepo.com

    Quelques outils

    1. Atlassian Design System
    2. Design system W3C
    3. Design system for Figma
    4. Design system de l’État
    5. Orbit open source design system
  • Réunion de lancement – Kick-off meeting

    La réunion de lancement est la première rencontre officielle entre toutes les parties prenantes d’un projet numérique (maître d’ouvrage, maître d’œuvre, prestataires, contributeurs, partenaires), dont l’objectif est de valider collectivement le cadre du projet, aligner les attentes, clarifier les rôles et activer la collaboration.

    Elle marque le passage de la phase de conception à la phase d’exécution, et s’appuie sur des documents préalables tels que :

    • Le cahier des charges (fonctionnel et/ou technique),
    • Le planning prévisionnel,
    • La cartographie des parties prenantes,
    • Les critères de succès et indicateurs de performance.

    Cette réunion n’est ni une présentation marketing, ni une simple prise de contact : c’est un acte fondateur de gouvernance, qui vise à :

    • Confirmer les objectifs, livrables et périmètre (et ce qui est exclu),
    • Présenter l’organisation du projet (rôles, responsabilités, points de décision),
    • Définir les modalités de communication (outils, fréquence des points, reporting),
    • Identifier les risques connus et les hypothèses de travail,
    • Instaurer un cadre de confiance et de transparence pour toute la durée du projet.

    Participants typiques

    • Maître d’ouvrage (décideur, financeur, représentant du besoin),
    • Chef de projet / AMOA (assistance à maîtrise d’ouvrage),
    • Équipe technique / maître d’œuvre (développeurs, intégrateurs, formateurs),
    • Utilisateurs finaux clés (si pertinent),
    • Partenaires externes (ex. : hébergeur, éditeur de solution).

    Durée & format

    • Durée : 1 à 2 heures (jamais plus — sinon, c’est mal préparé).
    • Format : en présentiel ou visio, toujours avec ordre du jour partagé à l’avance.
    • Livrable : un compte rendu signé listant décisions, actions, responsables et dates.

    Synonyme

    réunion de lancement

  • Daily scrum

    Le daily scrum ou mêlée quotidienne en méthode Scrum est la réunion qui a lieu tous les jours en début de journée.

    Elle permet à chaque membre de l’équipe de développement de partager son avancement et d’identifier les éventuels bugs et différents points de blocage.

    Elle dure 15mn au maximum où chaque membre de l’équipe fait le point sur ce qu’il a fait la veille.

  • Tests d’acceptation utilisateur – UAT

    Les tests d’acceptation utilisateur ( User Acceptance Testing ), sont une phase de tests dans le développement logiciel où les utilisateurs finaux évaluent l’application dans un système pour vérifier s’il répond à leurs besoins, s’il est convivial et s’il fonctionne conformément aux attentes.

    Les tests UAT permet de trouver d’éventuelles erreurs avant que votre produit web ne soit mis en ligne. 

    Au préalable les tests d’assurance qualité QA sont réalisés pour garantir le bon fonctionnement d’une application par les développeurs et équipes techniques avant qu’elle ne soit finalisée et soit envoyé pour les tests UAT en condition réelle par les utilisateurs finaux.

    C’est la validation par le maître d’ouvrage (ou ses représentants utilisateurs finaux) que le système répond bien aux besoins exprimés dans le cahier des charges fonctionnel.

    • Qui ? : Le client, les formateurs, les contributeurs, les apprenants (si représentatifs).
    • Quoi ? : Fonctionnalités, parcours utilisateur, règles métier, accessibilité fonctionnelle.
    • Comment ? : Scénarios réels : « Je m’inscris → je reçois un email → je télécharge mon certificat ».
    • Outil ? : Grille de recette basée sur le CSF, avec colonnes : exigence | test réalisé | résultat | statut (OK / KO).
    • Objectif : Accepter ou refuser la livraison avant paiement final.
  • Cahier des charges

    Le cahier des charges est un document formel, détaillé et souvent contractuel qui traduit, structure et valide les besoins d’un maître d’ouvrage (client, organisation, collectif) en exigences opérationnelles, fonctionnelles et techniques destinées au maître d’œuvre (prestataire, développeur, équipe interne).

    Il ne se contente pas de décrire « ce qu’on veut » : il définit précisément ce qui sera livré, comment cela sera mesuré, et dans quel cadre (délais, budget, contraintes).

    Il comprend généralement :

    • Le contexte et les objectifs du projet (pourquoi ?),
    • Les besoins fonctionnels (ce que le système doit faire : ex. « L’utilisateur peut s’inscrire, exporter ses données, recevoir des notifications »),
    • Les spécifications techniques (technos imposées, hébergement, compatibilité, sécurité, accessibilité WCAG…),
    • Les contraintes (juridiques, éthiques, culturelles, environnementales),
    • Le planning prévisionnel (jalons clés, dates de livraison),
    • Le budget ou les modalités de facturation,
    • Les critères de recette (comment on validera que c’est conforme).

    Contrairement au brief qui est un document stratégique, synthétique et orienté inspiration (souvent utilisé en amont pour aligner la vision) le cahier des charges est :

    • Vérifiable (chaque exigence doit être testable lors de la recette).
    • Technique (il parle de fonctionnalités, d’API, de formats),
    • Contractuel (il engage les parties),

    Distinction claire : cahier des charges vs brief

    CritèreBriefCahier des charges
    NatureStratégique, inspirantTechnique, normatif
    Public cibleÉquipe créative, chef de projetDéveloppeurs, prestataires, juristes
    ContenuVision, valeurs, cibles, tonFonctionnalités, specs, jalons, budget
    StatutInformatif, évolutifContractuel, validé, figé
    UsageAmorce du projetBase de la réalisation et de la recette

    Le brief dit « On veut construire une maison accueillante, lumineuse, en bois, pour une famille de 4 ».
    Le cahier des charges dit « 4 chambres, isolation RT2012, fenêtres double vitrage, surface 120 m², budget max 350 000 €, livraison en 10 mois ».

    Place du cahier des charges dans un projet

    ContexteDocument utilisé
    Phase amont / stratégieBrief → puis Cahier des charges (global)
    Phase réalisation / interneCSF (pour AMOA) + CST (pour équipe tech)
    Appel d’offres / marché publicCahier des charges (unique, obligatoire)
    Projet agile légerParfois remplacé par un backlog produit + user stories, mais le terme « cahier des charges » reste valide pour le cadre global
  • Accompagnement en numérique

    L’accompagnement en numérique est un processus collaboratif et personnalisé qui vise à aider une personne, une organisation ou une communauté à maîtriser, utiliser et transformer les outils numériques non pas comme des fins en soi, mais comme des moyens au service d’un projet humain, culturel, pédagogique ou professionnel.

    Il repose sur trois dimensions :

    1. Technique : comprendre les outils (WordPress, Omeka S, CRM, Git…), les configurer, les sécuriser, les maintenir.
    2. Pédagogique : apprendre à structurer, documenter, transmettre, créer du contenu de qualité.
    3. Stratégique : définir un objectif, cadrer un projet, choisir des solutions durables, éviter les dérives extractivistes.

    Contrairement à un simple « support technique » ou une « formation standard », l’accompagnement en numérique :

    • Est co-construit avec le bénéficiaire,
    • S’adapte à son niveau, ses besoins, sa culture,
    • Dure dans le temps (pas un coup d’éclat),
    • Vise la souveraineté numérique : que la personne ou l’organisation puisse continuer seule après.

    Ce n’est pas du “faire à la place”, mais du “faire avec” jusqu’à ce que l’autonomie soit acquise.