Proposition commerciale adalan

Proposition commerciale adalan

À partir d'une réunion client (fichier audio) ou d'une note écrite (Word, PDF, Markdown, e-mail, compte rendu), ce skill produit une proposition commerciale complète en pages HTML, toutes dans le même dossier :

Chaque slide de chaque deck porte un bouton « Accueil » (et la touche H) qui ramène à index.html. Les liens sont relatifs : les fichiers restent ensemble dans le même dossier.

Ce skill s'appuie sur deux autres skills, à charger au début :

• charte-graphique-adalan : la forme (feuille de style, logos, motifs, modèle de présentation). La bibliothèque de génération ci-dessous lit directement son dossier assets/ : si la charte change, il suffit de régénérer.
• presentation-adalan : ce qu'on dit d'adalan (pitch, offres, formules, clients citables, ton). Tout ce qui décrit adalan vient de là, jamais de mémoire.

S'il en manque un, le dire à l'utilisateur avant de commencer.

Déroulé

1. Ouvrir le dossier de l'affaire

<dossier de l'utilisateur>/<Client>/
  sources/                  les documents reçus (audio, notes), tels quels
  transcription.md          si la source est un audio
  brief.md                  le brief : la source de vérité
  index.html
  deck_0_synthese.html
  deck_1_<sujet>.html ...   un par proposition
  deck_<N+1>_budget.html
  mail.md                   le mail d'envoi (facultatif)
  build/                    adalan_decks.py, decks.py, check.js, captures/

• Le dossier est celui que l'utilisateur indique (souvent le dossier connecté qui contient la source). Ne jamais écrire dans le dépôt des skills.
• Ces fichiers contiennent des données client : ils ne se publient nulle part sans accord.

2. Transcrire l'audio (si la source est un enregistrement)

• Convertir en WAV 16 kHz mono : ffmpeg -i "<source>" -ar 16000 -ac 1 full.wav.
• Transcrire avec faster-whisper (pip install faster-whisper --break-system-packages), modèle medium, compute_type="int8", language="fr", vad_filter=True, beam_size=1, et un initial_prompt qui nomme le client et les participants (il améliore les noms propres). Compter environ 25 s de calcul par minute d'audio sur 2 cœurs : lancer en arrière-plan (nohup) et écrire les segments au fil de l'eau (début, fin, texte) pour suivre l'avancement.
• Tester d'abord la vitesse sur 60 s d'extrait ; small est 2 à 3 fois plus rapide mais nettement moins fiable sur les termes métier.
• Écrire transcription.md : en-tête (contexte, participants, source, durée, méthode), avertissement « transcription brute non relue », puis des paragraphes horodatés **[hh:mm:ss]** (regrouper les segments par pause de plus de 2,5 s ou toutes les 75 s).
• Corriger seulement les déformations certaines des noms connus (nom du client, d'adalan). Les locuteurs ne sont pas identifiés : le dire.
• Note écrite : lire le Word avec les outils docx, le PDF avec les outils pdf, le Markdown directement.

3. Construire le brief

Écrire brief.md. Chaque information porte sa source ([audio 00:14:20], [note], [entretien]), [déduit] pour une déduction, [à confirmer] pour un doute (chiffre ou nom mal transcrit), (interne) pour ce qui ne sort jamais dans un deck (concurrence, budget supposé, marge).

Rubriques (★ = nécessaire avant de rédiger) :

1. ★ L'affaire : client, entité, interlocuteurs (fonctions plutôt que noms), participants adalan, date et nature de la réunion, prochaine étape convenue.
2. ★ Le contexte et le besoin : organisation, outils, irritants, ce qu'ils coûtent (chiffres cités par le client), verbatims courts et exacts, ce qui a déjà été tenté.
3. Les exigences et contraintes : sécurité des données, gouvernance et validation, budget, SI, CSE, calendrier.
4. ★ Les opportunités : prioritaires (une proposition chacune) et secondaires (« autres pistes »), avec pour chacune le besoin, la solution, le périmètre réduit de départ, les prérequis, les objectifs proposés.
5. ★ Prix et conditions : montants fournis par l'utilisateur, repris tels quels ; mode de facturation, validité, échéancier, frais, propriété intellectuelle.
6. ★ La forme : signataires de l'affaire (nom et e-mail), références clients nommables, photos.
7. Points à confirmer et reste à compléter.

Règles de lecture d'une transcription :

• Seules les paroles du client font des verbatims ; celles d'adalan disent ce qui a déjà été promis, à reprendre avec cohérence.
• Les objections comptent autant que les besoins (« on a déjà essayé... », « pas de verrue ») : elles deviennent des exigences.
• Ce qui a été convenu en fin de réunion (« on vous envoie une proposition formation et deux POC ») fixe la liste des propositions.

4. Questionner sur ce qui manque, puis faire valider

• Utiliser l'outil de questions à choix (3 à 5 questions par message, les ★ d'abord), en proposant des hypothèses : « D'après la réunion, trois propositions : une formation et deux POC. Je confirme ? ».
• Questions types : quelles propositions retenir, quel périmètre réduit pour chaque POC (le rendre attractif en prix), quels montants, qui signe et quels contacts afficher (nom et e-mail de chaque signataire), peut-on nommer les références clients.
• « Je ne sais pas » devient un repère [à compléter : …].
• Arrêt obligatoire : présenter l'affaire en cinq lignes et la liste des propositions, et attendre l'accord avant de produire les decks. Si l'utilisateur veut avancer sans tout savoir, produire avec des repères et les lister au rendu.

5. Générer les pages

1. Créer build/ et y copier sans les modifier scripts/adalan_decks.py et scripts/check.js.
2. Écrire build/decks.py (contenu de l'affaire) en suivant les trames ci-dessous et l'exemple scripts/decks_exemple.py, puis lancer cd build && python3 decks.py.
3. La bibliothèque trouve seule le dossier assets/ de charte-graphique-adalan ; sinon définir ADALAN_CHARTE=<chemin de assets/>. Chaque page produite est autonome (CSS, logos et motifs intégrés) ; seules les polices et les photos Unsplash viennent d'internet.
4. Pour modifier un deck ensuite, modifier decks.py (ou brief.md puis decks.py) et régénérer : ne jamais retoucher le HTML produit à la main.

Trames des decks

Règles communes : une idée par slide, dite dans le titre en une phrase avec un mot accentué (<em>) ; trois cartes au plus par rangée ; un sur-titre qui situe sans répéter le titre ; data-section = « 01 · Partie » pour le pied de slide ; chaque deck commence par cover() et finit par merci().

deck_0 : synthèse de la réunion (12 à 14 slides)

1. cover : « Ce que nous avons entendu ».
2. qsn_general() : qui sommes-nous, puis refs() : les références clients en texte, par secteur.
3. L'atelier : qui était là (fonctions côté client, associés côté adalan), l'objectif, le périmètre.
4. Le contexte : trois cartes (organisation, outils, IA disponible...).
5. Les exigences : trois cartes (sécurité, pas de « verrues », budget...) et une note « Chaque proposition commence petit, mesure la valeur, puis s'étend. ».
6. section « Priorités », puis une slide qui présente les propositions en cartes (<small>Proposition 1</small>Titre).
7. Une slide par proposition : à gauche le besoin (ulist), à droite ink_box("Ce que nous proposons", [...]), via two_col.
8. Autres pistes : cartes et note pêche.
9. Prochaines étapes : steps (qui fait quoi : adalan, le client, ensemble).
10. merci().

deck_1 à deck_N : une proposition chacun (12 à 14 slides, sans prix)

1. cover avec sur-titre « Client · Direction · Proposition k ».
2. Qui sommes-nous adapté : qsn_formation() pour une formation, qsn_factory(1) pour un POC (l'étape « Prototyper » mise en avant), qsn_general() sinon ; puis refs().
3. L'enjeu : kpi() si le client a cité un chiffre (« environ 800 k€ par an »), avec « Ordre de grandeur communiqué lors de l'atelier ».
4. Aujourd'hui : trois cartes sur le problème, note pêche avec l'icône alert.
5. L'objectif : steps en 3 à 5 verbes (Collecter, Centraliser, Rapprocher, Décider).
6. Le périmètre réduit : table(["","Dans le POC","Plus tard"], ...). Un POC doit rester petit pour être attractif en prix : une entité, une boîte mail, un échantillon, sans intégration lourde au SI.
7. Comment ça marche : flow en 4 ou 5 boîtes (les boîtes IA ou humaines en encre).
8. Option éventuelle : split (texte sur encre et photo).
9. Planning : steps en semaines (S1, S2 à S4...).
10. Prérequis et objectifs : deux box côte à côte ; les objectifs chiffrés que le client n'a pas donnés portent « À valider ensemble lors du cadrage. ».
11. Valeur ou bénéfices : trois cartes.
12. La suite (« Après le POC » ou « Prochaines étapes ») : steps et note("Le budget de cette proposition est présenté <b>dans un document séparé.</b>", 8, "file", True).
13. merci().

Selon l'offre

• Formation ou parcours IA : constat, approche en temps (volet généraliste, diagnostic des outils, volet métier), une slide par volet, un zoom sur la session clé, le diagnostic en table, les cas d'usage métier. Le volet métier dépend des capacités réelles de l'outil du client (skills, connecteurs MCP, Cowork, projets) : le diagnostic vient d'abord.
• Factory (POC, outil, agent) : le chemin qualifier, prototyper, construire, déployer, transmettre ; proposer ferme le POC et en option la suite, à décider au bilan. Une slide ou une note applique la conformité au cas du client (AI Act, RGPD, données sensibles, shadow AI) et propose l'option souveraine si la sécurité des données est une exigence.
• Consulting (renfort, PMO, data) : le rôle en une phrase, le profil (prénom fourni ou profil type « Directeur(rice) de programme senior, verticale [à compléter] »), les premières semaines, et le temps IA : au moins 10 % du temps de mission, avec deux ou trois cas d'usage plausibles présentés comme des pistes à confirmer au démarrage.
• Appel d'offres : la trame imposée par le client passe avant ces trames ; ajouter un tableau de correspondance exigence par exigence et signaler au rendu les exigences non couvertes et les pièces à fournir.

deck_N+1 : budget (2 slides + 2 par proposition + 2)

1. cover : « Le budget, proposition par proposition ».
2. Vue d'ensemble : table(["Proposition","Contenu","Prix HT"], ..., price_col=2) avec une ligne par proposition et une ligne Total global, puis note « Les déploiements après les POC font l'objet d'un devis selon le bilan. ».
3. Pour chaque proposition : section, puis une slide two_col(table(["Élément","Prix HT"], ...), box("check","Ce qui est inclus", [...])).
4. Conditions : mode de facturation, validité de l'offre, échéancier, frais, propriété intellectuelle, confidentialité, chacune remplie depuis le brief ou en todo(...).
5. merci().

index.html

build_index("../index.html", kicker_client, "Nos propositions, <em>en un seul endroit.</em>", lead, groupes, facts=[...]) avec trois groupes : la synthèse seule et mise en avant (dernier champ True), puis « N propositions, pour démarrer petit. », puis « Le budget, à part. ». Chaque entrée : numéro, fichier, sur-titre, titre, une phrase, étiquettes (« 13 slides », « POC · 6 semaines »). Compter les slides réelles après génération (grep -o 'class="slide' fichier | wc -l).

Règles de rédaction

• Le client d'abord : son contexte, ses mots, ses chiffres avant adalan. Citer une fonction plutôt qu'un nom, sauf accord.
• Un titre, un message : « Un PMO qui anticipe au lieu de consolider », pas « Notre approche ».
• Du concret : livrables, semaines, rôles, périmètres. Pas de superlatif ni de jargon de plaquette.
• La voix d'adalan : nom en minuscules partout, « nous » et « vous », écriture inclusive, formules de référence de presentation-adalan reprises telles quelles. La bibliothèque applique la typographie française (espaces insécables, apostrophes).
• Une seule source de vérité : mêmes chiffres, dates et noms dans le brief, les decks, l'accueil et le mail. Les dates de planning déduites d'un démarrage et de durées portent [déduit] et passent par la validation.
• Contacts : aucun nom n'est fixé dans ce skill. Les signataires de l'affaire (nom et e-mail) sont demandés à l'utilisateur, puis renseignés dans decks.py avec CONTACTS[:] = [("Prénom Nom", "adresse@adalan.fr"), ...] : ils apparaissent sur la slide de clôture de chaque deck et dans l'encart de fin de l'accueil. Sans signataire, seule l'adresse contact@adalan.fr apparaît. Le pied de l'accueil porte toujours contact@adalan.fr.

Prix et conditions

• Les prix n'apparaissent que dans le deck budget. Aucun deck de proposition ne contient de montant.
• Les montants donnés par l'utilisateur sont repris tels quels. Ceux qui manquent deviennent todo("prix du POC") (repère pêche visible).
• Total global : seulement si tous les montants sont fournis, calculé par le script Python (jamais de tête), et signalé au rendu pour vérification ; sinon todo("total global HT"). Aucune TVA, remise ni échéance calculée.
• Aucun tarif dans ce skill : ne jamais inventer de grille, de TJM ni de conditions. Si l'utilisateur tient ses tarifs dans un fichier, l'utiliser quand il l'indique.
• La propriété intellectuelle se décide par un(e) associé(e) : todo("propriété intellectuelle, à valider par un associé") si le brief ne la tranche pas.

Rien d'inventé

• Aucun chiffre, résultat, témoignage, certification ou engagement de service (délai de remplacement, pénalités, garanties) qui ne vienne des sources ou de l'utilisateur. Les objectifs chiffrés proposés par adalan sont présentés « à valider ensemble ».
• Références : seulement les clients de presentation-adalan (fonction refs()), en texte par secteur, sans rien dire des missions menées chez eux ; le client de l'affaire n'y figure jamais.
• Photos : celles du modèle de la charte (déjà dans la bibliothèque) ou des photos Unsplash trouvées avec un outil de recherche, créditées. Jamais d'adresse inventée.
• Rien de ce que le brief marque (interne). Aucun chiffre non public d'adalan (chiffre d'affaires, effectif) sans accord explicite.

Vérifier et rendre

1. cd build && NODE_PATH=$(npm root -g) node check.js (Playwright pour Node, une fois : npm install -g playwright && npx playwright install chromium) : signale tout débordement hors de la zone utile, fait une capture par slide dans build/captures/, exporte chaque deck en PDF et vérifie que l'accueil ne défile pas horizontalement sur mobile. Corriger chaque débordement (texte plus court, small=True pour un titre long, moins de lignes) et relancer.
2. Regarder quelques captures (couverture, slide la plus dense, budget, clôture) et l'accueil.
3. Compter les repères : grep -o 'class="todo"' ../*.html | wc -l.
4. Vérifier l'absence du caractère tiret long dans les textes si l'utilisateur l'a demandé.
5. Si le dossier de l'affaire est sur l'ordinateur de l'utilisateur, y écrire les fichiers produits (pas build/captures/).
6. Rendre en quelques lignes : les fichiers produits, le nombre de slides par deck, les repères restants deck par deck, les points à confirmer, et ce qui a été déduit plutôt qu'entendu.

Le mail d'envoi (facultatif, dans mail.md) : un objet qui nomme le client, 80 à 150 mots, ce qui est joint (le lien ou le dossier des pages), deux ou trois points qui comptent, la prochaine étape, la signature du signataire. L'utilisateur l'envoie lui-même.

Navigation dans les decks

Flèches, Espace, Entrée, Page suivante et précédente ; Début et Fin ; F plein écran ; H ou Échap retour à l'accueil (Échap quitte d'abord le plein écran) ; #5 dans l'adresse ouvre la slide 5 ; ?static fige les animations ; l'impression sort une slide par page au format 1920 × 1080, fonds compris, sans le bouton Accueil.

Exemple

Demande : « Voici l'enregistrement de notre réunion chez le client. Fais-moi la proposition commerciale. »

Résultat attendu :

1. transcription.md, puis brief.md avec les opportunités repérées, chacune avec sa source horodatée.
2. Une série de questions : « Trois propositions d'après la fin de réunion : une formation et deux POC, je confirme ? Quel périmètre réduit pour chaque POC ? Quels montants ? Qui signe, avec quelle adresse e-mail ? ».
3. Après l'accord : index.html, deck_0_synthese.html, deck_1_formation.html, deck_2_poc_xxx.html, deck_3_poc_yyy.html, deck_4_budget.html, vérifiés par check.js, et la liste des repères restants (prix, total global, propriété intellectuelle).

Vérification finale

• Le brief a été validé ; la liste des propositions vient de la réunion ou de l'utilisateur.
• index.html, deck_0, un deck par proposition et le deck budget existent dans le même dossier ; tous les liens de l'accueil s'ouvrent ; chaque slide a son bouton Accueil.
• Aucun prix hors du deck budget ; aucun montant inventé ; le total global est calculé par script ou laissé en repère.
• Les contacts affichés sont ceux des signataires de l'affaire, ou contact@adalan.fr à défaut.
• check.js ne signale aucun débordement ; les PDF ont une slide par page.
• Nom adalan en minuscules, formules de presentation-adalan, charte respectée, typographie française.
• Chaque repère [à compléter : …] est listé au rendu.
• Le dossier de l'affaire est hors du dépôt des skills.

Bibliothèque scripts/adalan_decks.py

À copier telle quelle dans build/. Fonctions de slides : cover, section, light, split, kpi, merci, qsn_general, qsn_formation, qsn_factory, refs ; composants : cards (liste de tuples (icône, titre, texte) ou (icône, titre, "", None, [puces]), n=2|3|4), note, steps ([(repère, titre, texte)], hl= index en encre), table (price_col= colonne en Monaspace pêche), ulist, flow ([(étiquette, titre, texte, encre?)]), two_col, ink_box, box, todo ; assemblage : build(titre, description, html, fichier) et build_index(...) ; contacts : CONTACTS. Icônes disponibles : check, clock, mail, shield, users, mic, database, target, link, alert, file, chart, lock, layers, coins, phone, gift, cpu, home, arrow, search, hammer, cap, flag.