# Business It Commercial Proposal > Génération d'offres commerciales pour des projets IT — lots techniques, chiffrage jour-homme, hypothèses, SLA, TMA et annexes techniques. Se déclenche avec "offre commerciale IT", "proposition commerciale IT", "devis IT", "appel d'offres", "offre technique et financière", "chiffrage jour-homme", "SOW", "réponse à AO". Also triggers on "IT project proposal", "software quote", "SOW for a client". - Skill: `khalilbenaz/business-it-commercial-proposal` (Agent Skill) - Install (CLI): `npx skillmds@latest add khalilbenaz/business-it-commercial-proposal` - Raw SKILL.md: https://api.skillmd.com/api/skills/khalilbenaz/business-it-commercial-proposal/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: khalilbenaz (https://skillmd.com/u/khalilbenaz) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/khalilbenaz/business-it-commercial-proposal --- # IT Commercial Proposal Generator ## Workflow ### Étape 1 — Cadrage du besoin Avant d'écrire une seule ligne, extraire ces informations du client : ``` CONTEXTE : secteur, taille entreprise, périmètre fonctionnel PROBLÈME : pain point actuel, coût de l'inaction OBJECTIFS : KPI cibles (délai de traitement, taux d'erreur, SLA...) CONTRAINTES : budget indicatif, deadline, stack imposée, normes (RGPD, PCI-DSS...) DÉCIDEURS : qui signe ? (DG, DSI, DAF) — cela dicte le ton AO/GRÉ À GRÉ : réponse à appel d'offres formel (2 enveloppes) ou négociation directe ? ``` Si une information manque, générer une liste de questions de cadrage structurées et les poser en bloc — pas au fil de la génération. **Critère de passage** : ne pas produire l'offre tant que contexte + objectifs + contraintes budget ne sont pas connus. --- ### Étape 2 — Structure de l'offre (ordre de rédaction interne) Rédiger dans cet ordre (l'executive summary se place en tête dans le livrable final mais se rédige en dernier) : | # | Section | Destinataire principal | Longueur cible | |---|---------|----------------------|----------------| | 1 | Compréhension du besoin | Tous | 1/2 page | | 2 | Solution proposée + architecture | DSI / CTO | 1–2 pages | | 3 | Méthodologie & livrables | Chef de projet | 1 page | | 4 | Planning (phases + jalons) | Chef de projet | tableau | | 5 | Équipe projet | DSI / DRH | 1/2 page | | 6 | Chiffrage financier | DAF / DG | tableau | | 7 | Références similaires | Tous | 1/2 page | | 8 | Conditions contractuelles | Juridique | 1/2 page | | 9 | **Executive Summary** (rédigé en dernier) | DG / DAF | 1/2 page max | --- ### Étape 3 — Rédiger chaque section **Compréhension du besoin** Reformuler mot pour mot ce que le client a exprimé, puis compléter avec les enjeux business sous-jacents. Cela crédibilise l'offre et prouve l'écoute. **Solution proposée** - Décrire l'architecture cible en 3–5 composants clés avec le nom des technologies choisies et la justification du choix (ex. : "PostgreSQL plutôt qu'Oracle : réduction TCO de 60%, compétences internes disponibles"). - Inclure un schéma textuel ou ASCII si un vrai diagramme n'est pas disponible : ``` [Frontend React] → [API Gateway (Kong)] → [Microservices .NET 8] ↓ [PostgreSQL 16] + [Redis cache] ``` **Chiffrage financier — modèle de tableau** ``` Profil | TJM (€HT) | Jours Phase 1 | Jours Phase 2 | Total jours | Coût HT --------------------|-----------|---------------|---------------|-------------|---------- Chef de projet | 800 | 10 | 5 | 15 | 12 000 Architecte solution | 1 000 | 5 | 2 | 7 | 7 000 Développeur senior | 700 | 20 | 30 | 50 | 35 000 QA / Test | 600 | 0 | 10 | 10 | 6 000 TOTAL | | | | | 60 000 TVA 20% | | | | | 12 000 TOTAL TTC | | | | | 72 000 ``` Toujours préciser : - Mode de facturation : forfait fixe / régie / abonnement mensuel - Jalons de paiement (ex. : 30% à la commande, 40% à la livraison phase 1, 30% à la recette finale) - Exclusions explicites : licences tierces, hébergement, déplacements au-delà de 50 km, formations - Validité de l'offre : 30 ou 60 jours selon le contexte **Options / variantes (toujours proposer au moins deux)** ``` Option A — MVP (4 mois) : 42 000 € HT — fonctionnalités core uniquement Option B — Complet (7 mois): 60 000 € HT — intégrations + reporting + maintenance 6 mois incluse ``` **Executive Summary (rédigé en dernier)** 5 questions auxquelles il doit répondre en moins de 20 lignes : 1. Quel est le problème client ? 2. Quelle est la solution proposée ? 3. Pourquoi nous (différenciation) ? 4. Quelle valeur / ROI attendu ? 5. Quand et pour quel budget ? --- ### Étape 4 — Adapter le ton selon le décideur | Interlocuteur | Priorités à mettre en avant | Ce qu'il faut éviter | |---------------|----------------------------|----------------------| | DG / CEO | ROI, délai de retour sur investissement, risque business | Détails techniques | | DAF / CFO | Coût total de possession (TCO), modèle de facturation, risques budgétaires | Acronymes tech | | DSI / CTO | Architecture, maintenabilité, sécurité, performance, scalabilité | Jargon business vague | | Chef de projet | Planning détaillé, livrables, critères de recette, gouvernance | ROI financier | --- ### Étape 5 — Relecture et qualification finale Checklist avant livraison : - [ ] Chiffrage cohérent avec le planning (nb jours × TJM = total) - [ ] Aucun engagement hors scope non chiffré - [ ] Date de validité présente - [ ] Deux enveloppes séparées si AO formel - [ ] Orthographe et grammaire irréprochables - [ ] Executive summary auto-suffisant (peut se lire seul) - [ ] Variante MVP + variante complète proposées - [ ] Références client avec secteur + résultat mesurable --- ## Garde-fous et anti-patterns **Ne pas faire** - **Lister des fonctionnalités** au lieu de bénéfices : "Nous livrons un module de reporting" → inutile. Dire : "Le reporting temps réel réduit le délai de clôture mensuelle de 3 jours à 4 heures." - **Chiffrage opaque** : un forfait global sans décomposition est un signal d'alarme pour tout acheteur public ou DSI expérimenté. - **Promettre sans engagement contractuel** : toute promesse de délai ou de performance doit être accompagnée d'un critère de recette mesurable. - **Executive summary générique** : copier-coller un template sans personnaliser au contexte client — se voit immédiatement et disqualifie l'offre. - **Ignorer les contraintes réglementaires** : pour les secteurs banque, santé, assurance — mentionner explicitement la conformité RGPD, PCI-DSS, ISO 27001, etc. - **TJM sans justification pour des profils senior** : si les taux sont élevés, les justifier par la rareté du profil ou la criticité du projet. **Pièges fréquents** - Oublier la TVA ou le régime fiscal applicable (AO public : HT obligatoire, TVA séparée) - Ne pas distinguer régie et forfait dans le même document - Proposer un planning sans marge de risque (ajouter 15–20% de buffer sur les phases d'intégration) - Référencer des technologies obsolètes ou abandonnées en 2026 (ex. : Angular 1, jQuery comme stack principale) --- ## Bonnes pratiques 2026 - **AI-augmented delivery** : si l'équipe utilise des outils IA (GitHub Copilot, Cursor, Claude Code), le mentionner comme accélérateur de productivité — c'est désormais un différenciateur positif attendu par les DSI modernes. - **Green IT** : pour les projets cloud, estimer l'empreinte carbone et proposer des choix d'architecture éco-responsables (régions Azure/AWS à énergie renouvelable, right-sizing, serverless). - **Sécurité by design** : intégrer une section ou un paragraphe dédié à la posture sécurité (SAST/DAST dans la CI, gestion des secrets, politiques RBAC) — désormais exigé dans la majorité des AO publics et grandes entreprises. - **Modèle de facturation flexible** : proposer un abonnement SaaS ou TaaS (Team as a Service) mensuel en alternative au forfait projet — tendance forte en 2025–2026 pour les prestataires IT. - **SLA chiffré** : pour toute offre incluant de la maintenance ou du run, inclure un tableau de SLA avec niveaux de criticité, temps de réponse et pénalités contractuelles. ## Communication Rules — MANDATORY - Ultra-concise. No filler, no preamble, no pleasantries. - Never say "happy to help", "sure!", "great question", "let me", or similar. - Tool first, talk second. Act before explaining. - Result first. Lead with outcome, not process. - Stop when done. No summary, no recap, no trailing commentary. - No politeness wrappers. Direct and blunt. - Minimum words. If one word works, do not use ten. - No unsolicited explanations. - No emoji unless asked.