Feuille de route opérationnelle — Colead Finance

Préambule — Résultat des trois vérifications préalables#

1. Incohérences majeures. Le cabinet est Colead Finance ; Zied Elarbi et Anis Maalej sont experts-comptables, membres de la CNCC et signataires. Les incohérences restantes portent sur l'absence de clients nommés, la date de la réunion du mardi non fixée, les délais qui se chevauchent, la cadence de 3 AO par semaine non reliée à la capacité, l'absence de propriétaires nominatifs pour les actions, les références et CV non inventoriés, les règles d'éligibilité et les outils non écrits, et les montants absents. Le document source est un brief de cadrage, pas un verbatim de réunion.

2. Décisions vs discussions. Trois faits structurants sont confirmés : le cabinet est Colead Finance ; Zied Elarbi et Anis Maalej sont signataires ; tous deux sont experts-comptables et membres de la CNCC. Trois engagements de cadrage peuvent être retenus (structurer le processus, semi-automatiser à environ 50 %, maintenir une validation humaine), mais ils doivent être formalisés. Les 14 missions, les usages de l'IA, les outils, les partenariats et les KPI sont des discussions ou des objectifs, pas des décisions.

3. Sujets hors périmètre. Sont exclus : la rédaction complète d'une réponse à un AO ; la stratégie commerciale globale ; le recrutement ; la refonte complète du SI ; le contentieux ; les documents de concurrents sans droits ; les dépôts automatisés sans validation humaine ; et les partenariats non formalisés. Les échanges sans lien direct avec le processus AO ne sont pas repris dans ce document.

La suite du document applique la structure imposée en 20 sections, puis la section de validation finale.

0. Note de méthode#

0.1 Quatre règles de construction#

1. Ne rien inventer. Toute information absente est signalée comme manquante, jamais comblée par une hypothèse présentée comme un fait.
2. Séparer les registres. Une décision, un engagement, un objectif, une discussion, une hypothèse et une information manquante ne sont pas équivalents.
3. Tracer. Chaque décision, action, référence et version doit avoir un identifiant, un propriétaire, une date et une preuve.
4. Valider humainement. Aucune production sensible (Go/No-Go, référence, CV, prix, signature, dépôt) ne peut être validée par une IA seule.

0.2 Codes utilisés#

0.3 Niveaux de confiance#

0.4 Convention de responsabilité#

Les mentions « proposé » indiquent une répartition de travail recommandée, pas une nomination. Toute nomination doit être confirmée par le sponsor du projet et consignée dans le journal des décisions. Les mentions « à valider » indiquent une information que la source ne permet pas de trancher.

1. Synthèse exécutive#

Le cabinet dispose d'une intention claire : industrialiser la gestion des appels d'offres, réduire le temps de préparation, améliorer la rentabilité et augmenter la cadence de réponse, avec une semi-automatisation et une validation humaine obligatoire. Le brief fixe aussi une ambition de rythme (environ trois AO validés par semaine), une échéance courte (un mois) et un ensemble de livrables structurés.

La difficulté n'est pas l'ambition : c'est l'écart entre le brief et les actifs disponibles. Le cabinet est Colead Finance et les deux signataires sont identifiés, mais aucun client n'est nommé, les propriétaires des actions ne sont pas désignés, les références et CV ne sont pas inventoriés, les règles d'éligibilité ne sont pas écrites, les outils ne sont pas choisis et les montants ne sont pas connus. Le système peut donc être conçu et testé, mais pas encore produit à cadence réelle sans une phase courte de vérification et de formalisation.

1.1 Ce que le système doit permettre#

1.2 Les cinq décisions qui conditionnent tout#

1. Répartition des mandats de signature entre Zied et Anis et pouvoirs associés.
2. Périmètre prioritaire des missions et des zones géographiques.
3. Capacité cible : cadence, nombre d'AO en cours, seuil de rentabilité.
4. Chaîne d'outils et règles de confidentialité des données.
5. RACI de validation finale et interdiction de tout dépôt sans validation humaine.

1.3 Chemin critique#

Mandats de signature Zied / Anis et pièces CNCC
        ↓
Référentiel d'éligibilité et règles bailleurs
        ↓
Base de références autorisées + base CV
        ↓
Scoring Go/No-Go et modèles de décision
        ↓
Deux dossiers pilotes
        ↓
Contrôle qualité et validation finale
        ↓
Mise en production contrôlée

1.4 Message clé#

Le projet ne doit pas être vendu comme « 50 % d'automatisation » avant d'avoir mesuré le temps réel de préparation sur deux dossiers historiques. La première victoire n'est pas un outil : c'est un processus traçable, des références fiables et une décision Go/No-Go disciplinée. L'automatisation vient ensuite, sur des tâches répétables et contrôlables.

2. Évaluation de la qualité des notes#

2.1 Constat global#

Conclusion de qualité : la source est suffisante pour concevoir un dispositif, insuffisante pour lancer une production à cadence réelle. Elle doit être complétée par un relevé de décisions, un journal d'actions et une validation des informations critiques.

2.2 Incohérences identifiées#

2.3 Décisions, discussions, hypothèses et manques#

2.4 Sujets hors périmètre#

2.5 Conclusion#

Les notes sont exploitables comme brief de conception, pas comme procès-verbal de décision. La feuille de route ci-dessous est donc construite avec des hypothèses explicites, des responsables proposés et des points de validation. Elle ne doit pas être lue comme un engagement du cabinet ni comme une validation juridique.

3. Décisions confirmées#

3.1 Décisions formelles tracées#

Trois faits structurants sont confirmés : le cabinet est Colead Finance ; Zied Elarbi et Anis Maalej sont signataires ; tous deux sont experts-comptables et membres de la CNCC. En revanche, la source ne contient ni journal de décisions, ni relevé signé, ni décision explicite sur le périmètre, la capacité, les outils ou la RACI. Les éléments disponibles sont des objectifs, des exigences de cadrage ou des discussions.

3.2 Engagements de cadrage à formaliser#

3.3 Objectifs annoncés, non validés#

3.4 Règle de gouvernance#

Toute nouvelle décision doit être consignée dans un journal des décisions avec : identifiant, date, objet, décision, propriétaire, preuve, impact et date de revue. Une discussion non consignée reste une discussion.

4. Actions attribuées#

4.1 Constat#

Les signataires sont identifiés, mais aucune action nominative n'est attribuée dans la source. Les quatre participants sont cités ; aucun ne porte explicitement une action, une échéance ou un livrable. Les 18 actions de la section 17 du brief sont des actions à faire, pas des actions attribuées.

4.2 Actions implicites et responsables proposés#

4.3 Règle d'attribution#

Aucune action ne peut entrer en production sans un responsable nommé, une échéance et un livrable. Une action « proposée » ne devient officielle qu'après validation dans le journal des décisions.

5. Points à vérifier#

6. Processus cible complet#

6.1 Architecture en cinq phases et deux transverses#

flowchart LR
    A["Détecter"] --> B["Qualifier"]
    B --> C["Préparer"]
    C --> D["Contrôler"]
    D --> E["Envoyer"]
    E --> F["Archiver"]
    F --> G["Apprendre"]
    G --> A

6.2 Les 23 étapes#

Légende des tableaux : Resp. = responsable proposé ; Contr. = contributeurs ; Valid. = validation obligatoire ; Délai = délai cible relatif à la détection (J0) ou à la date limite (J-x).

Phase Détecter

Phase Qualifier

Phase Préparer

Phase Contrôler

Phase Envoyer et apprendre

6.3 Portes de passage#

6.4 Règles de capacité et de priorisation#

Point de vigilance. L'objectif de 3 AO validés par semaine n'est pas compatible, en l'état, avec une équipe de quatre personnes, un processus manuel naissant et une validation humaine sur chaque production. La cadence doit être mesurée avant d'être promise.

7. Matrice RACI#

7.1 Rôles#

Règle RACI. Une seule personne est A (Accountable) par activité. Le R fait le travail. Le C est consulté avant décision. Le I est informé. Zied et Anis sont signataires ; la répartition des dossiers et les délégations doivent être formalisées.

7.2 Matrice proposée#

7.3 Écarts et règles de secours#

8. Tableau de veille#

8.1 Principes#

1. Source unique de vérité. Un seul tableau de veille, pas de copies parallèles.
2. Identifiant unique. Chaque opportunité reçoit un ID AO-AAAA-NNN.
3. Traçabilité. Chaque champ critique est relié à une source ou à une preuve.
4. Déduplication. Une opportunité = un acheteur + un objet + une date limite + un lien.
5. Statut explicite. Aucun dossier ne peut sauter une étape du workflow.
6. Alerte avant échéance. J-10 orange, J-5 rouge, J-2 critique.

8.2 Dictionnaire des 49 champs#

8.3 Workflow des statuts#

8.4 Règles d'alerte et de blocage#

8.5 Vues opérationnelles#

1. Vue Lundi : opportunités détectées, qualifiées, Go/No-Go de la semaine.
2. Vue Pipeline : AO actifs par statut et par responsable.
3. Vue Échéances : J-10, J-5, J-2, retards.
4. Vue Pièces manquantes : par AO et par type de pièce.
5. Vue Partenaires : partenaires nécessaires, contactés, formalisés.
6. Vue Finance : budget, honoraires, marge, coût de préparation.
7. Vue Qualité : erreurs, corrections, conformité.
8. Vue Résultats : gagnés, perdus, causes, REX.

8.6 Détection des doublons#

8.7 Sources de veille à configurer#

Règle de conformité. La collecte doit respecter les conditions d'utilisation des sources. Aucune extraction massive, aucun contournement d'accès, aucun scraping non autorisé. Les sources incertaines sont validées par Zied avant intégration.

9. Scoring Go/No-Go#

9.1 Principes#

1. Le score ne neutralise jamais un critère éliminatoire. Un seul critère éliminatoire non satisfait suffit à un No-Go ou à une escalade.
2. Le score est une aide à la décision, pas une décision. La décision est humaine, tracée et signée.
3. La confiance est distincte du score. Un bon score sur des données douteuses reste une incertitude.
4. Chaque point doit être justifié par une preuve ou une source.
5. Le score est recalculé si une information critique change.

9.2 Grille sur 100 points#

9.3 Seuils de décision#

9.4 Score de confiance#

9.5 Critères éliminatoires#

9.6 Matrice de décision complète#

9.7 Gouvernance de la décision#

10. Architecture documentaire#

10.1 Arborescence#

00_Gouvernance_Processus
01_Veille_Appels_Offres
02_TDR_Originaux
03_Eligibilite
04_References_Cabinet
05_References_Equipe
06_Partenaires
07_CV
08_Modeles_Reponses
09_Offres_En_Cours
10_Offres_Soumises
11_Offres_Gagnees
12_Offres_Non_Retenues
13_Archives
14_Retours_Experience

Chaque dossier 09_Offres_En_Cours contient un sous-dossier par AO :

AO-2026-001_Organisme_Pays/
    01_TDR
    02_Administratif
    03_Technique
    04_Financier
    05_References
    06_CV
    07_Controle
    08_Depot
    09_Archives

10.2 Convention de nommage#

Format : AAAA-MM-JJ_Organisme_Pays_TypeMission_Reference_Version_Statut.ext

Exemple : 2026-10-22_AFD_Tunisie_AuditDepenses_AO-2026-001_V01_BROUILLON.docx

10.3 Gestion des versions#

Règles : - Ne jamais écraser une version validée. - Conserver un journal des versions avec date, auteur, changement et approbateur. - La version envoyée et la version source sont archivées ensemble. - Toute correction après envoi crée une nouvelle version, jamais une modification silencieuse.

10.4 Droits d'accès#

Règles : MFA obligatoire ; moindre privilège ; revue trimestrielle des accès ; journalisation ; aucun partage par lien public.

10.5 Conservation et archivage#

Les durées sont des propositions de travail. Elles doivent être validées par le conseil juridique du cabinet avant application.

10.6 Sauvegarde et sécurité#

10.7 Procédure de suppression#

1. Vérifier la durée de conservation.
2. Obtenir l'accord écrit de Zied.
3. Archiver une copie si nécessaire.
4. Supprimer uniquement la version concernée.
5. Consigner la suppression dans le journal des versions.

11. Automatisations prioritaires#

11.1 Principes#

• Human-in-the-loop sur toute décision et toute production sensible.
• Aucun envoi automatique vers une plateforme de dépôt.
• Aucune invention : l'IA cite ses sources ou signale l'absence.
• Traçabilité : chaque sortie automatique est datée, versionnée et associée à un modèle.
• Réversibilité : possibilité de revenir à un processus manuel.
• Sécurité : données sensibles dans un environnement contrôlé, pas dans un outil public.

11.2 Niveau 1 — Automatisation immédiate#

11.3 Niveau 2 — Automatisation intermédiaire#

11.4 Niveau 3 — Automatisation avancée#

Interdiction temporaire. La connexion aux plateformes de dépôt ne doit pas être activée avant six mois de fonctionnement stable, deux audits de sécurité et une validation écrite de Zied. Aucun envoi automatique n'est autorisé.

11.5 Séquencement recommandé#

11.6 Critères de choix build vs buy#

11.7 Exigences pour un outil d'IA#

1. Ne pas entraîner de modèle sur les données du cabinet.
2. Hébergement et traitement conformes aux règles de confidentialité.
3. Chiffrement, contrôle d'accès, journalisation.
4. Citations des sources et sorties structurées.
5. Versionnement des modèles et des prompts.
6. Possibilité de désactiver l'IA et de revenir au manuel.
7. Contrat de traitement des données et clause de confidentialité.

12. Bibliothèque de prompts#

12.1 Règles communes à tous les prompts#

1. Ne rien inventer. Si une information est absente, écrire « information manquante ».
2. Distinguer explicitement FAIT, HYPOTHÈSE, INFORMATION MANQUANTE.
3. Signaler les contradictions entre documents.
4. Citer la source : document, section, page si possible.
5. Demander une validation humaine en cas d'incertitude.
6. Ne jamais utiliser une référence non vérifiée.
7. Ne jamais présenter une sortie comme une validation juridique ou réglementaire.

12.2 Format de sortie standard#

1. Objet
2. Faits établis (avec sources)
3. Hypothèses
4. Informations manquantes
5. Contradictions détectées
6. Analyse / recommandation
7. Niveau de confiance (élevé / moyen / faible)
8. Validation humaine requise (oui/non + motif)

12.3 Prompt maître#

RÔLE : Tu es un analyste senior en appels d'offres, spécialisé dans les missions d'audit et de finance.
OBJECTIF : [décrire la tâche].
ENTRÉES : [documents, sections, tableaux].
TÂCHE : [instructions précises].
FORMAT : respecte le format de sortie standard.
RÈGLES :
- ne rien inventer ;
- distinguer faits, hypothèses et informations manquantes ;
- signaler les contradictions ;
- citer les sources ;
- demander une validation humaine en cas d'incertitude ;
- ne jamais utiliser une référence non vérifiée ;
- ne jamais présenter la sortie comme une validation juridique.
INTERDICTIONS : [liste spécifique].
CONTRÔLE FINAL : vérifier que chaque affirmation est sourcée ou marquée comme hypothèse.

12.4 Les 20 prompts#

12.5 Cycle de vie des prompts#

12.6 Évaluation des prompts#

13. Modèles à produire#

13.1 Modèles prioritaires pour la semaine 1#

1. Fiche d'opportunité.
2. Fiche Go/No-Go.
3. Checklist administrative.
4. Checklist de dépôt.
5. Journal des décisions.

13.2 Règle de validation des modèles#

Un modèle n'est utilisable en production qu'après : validation du contenu, test sur un dossier historique, validation par le propriétaire du processus et enregistrement de la version.

14. Planning sur quatre semaines#

14.1 Calendrier de référence#

Cohérence avec l'objectif « 1 mois ». Le 22 octobre 2026 + 1 mois = 21 novembre 2026. La semaine 4 se termine le 20 novembre 2026, ce qui laisse une marge d'un jour. Cette marge ne doit pas être consommée par des décisions non prises en semaine 1.

14.2 Plan d'action détaillé#

14.3 Chemin critique#

S1.2 Mandats de signature Zied / Anis
    → S1.4 Inventaire des références et CV
    → S2.3 Modèles et S2.4 Prompts
    → S3.2 Références et S3.3 CV
    → S3.6 Tests sur dossiers historiques
    → S4.2 Dossiers réels
    → S4.7 Décision de production

Règle : si S1.2 n'est pas terminée le 23 octobre 2026 à 17h, tout le planning glisse d'au moins une semaine. Il ne faut pas compenser ce retard en supprimant les tests.

14.4 Gouvernance du planning#

14.5 Définition de « terminé »#

Une action est terminée lorsque : le livrable existe, il est validé par le responsable indiqué, il est stocké au bon endroit, sa version est enregistrée et le critère de réussite est démontré par une preuve.

15. Réunion du mardi#

15.1 Date à confirmer#

Le brief mentionne « le mardi à 14h » sans date. Le premier mardi après le 22 octobre 2026 est le 27 octobre 2026, mais le processus ne peut pas être prêt en trois jours ouvrés. Trois options :

Recommandation : tenir une réunion de cadrage le 27 octobre 2026 et la réunion de validation du processus le 3 novembre 2026. Les deux dates doivent être confirmées par Zied.

15.2 Ordre du jour proposé — 14h00 à 16h40#

15.3 Décisions obligatoires pendant la réunion#

15.4 Pack de préparation#

À envoyer 48 heures avant la réunion :

1. Note de synthèse des incohérences.
2. Processus cible en 23 étapes.
3. Grille de scoring et règles de décision.
4. Tableau de veille et dictionnaire des champs.
5. RACI proposée.
6. Arborescence documentaire.
7. Deux exemples de prompts.
8. Démonstration sur un dossier historique.
9. Liste des décisions à prendre.
10. Journal des décisions à signer.

15.5 Modèle de compte rendu#

15.6 Règles de facilitation#

1. Une discussion sans décision est notée comme discussion, pas comme décision.
2. Toute décision doit avoir un propriétaire et une date.
3. Les désaccords sont consignés, pas effacés.
4. Aucune décision irréversible n'est prise sans les documents de preuve.
5. Le compte rendu est diffusé sous 24 heures et validé sous 48 heures.

16. Indicateurs de performance#

16.1 Principes#

• Pas de KPI sans source. Chaque indicateur doit être calculé à partir du tableau de veille, du registre des soumissions ou du modèle financier.
• Baseline d'abord. Les deux premières semaines servent à mesurer l'existant, pas à atteindre une cible.
• Cibles provisoires. Les cibles ci-dessous sont des propositions à valider après la baseline.
• Un indicateur, un propriétaire. Personne ne pilote un indicateur sans mandat.

16.2 Tableau de bord#

16.3 Vues du tableau de bord#

1. Pipeline : volume, statut, responsable, échéance.
2. Qualité : conformité, erreurs, corrections.
3. Finance : budget, honoraires, marge, coût de préparation.
4. Partenariats : contacts, accords, références.
5. IA : prompts utilisés, corrections, incidents.
6. Apprentissage : REX, causes de rejet, actions.

16.4 Règles de qualité des données#

16.5 Rythme de revue#

17. Registre des risques#

17.1 Méthode#

• Probabilité (P) : 1 = rare, 5 = quasi certain.
• Impact (I) : 1 = mineur, 5 = critique.
• Criticité (C) = P × I.
• Niveaux : 1–4 faible ; 5–9 moyen ; 10–14 élevé ; 15–25 critique.
• Les valeurs P et I sont des estimations initiales à calibrer après les deux dossiers pilotes. Elles ne doivent pas être présentées comme des mesures historiques.

17.2 Registre#

17.3 Top 5 des risques#

1. R1 — Hallucination de l'IA. Risque le plus probable et le plus dommageable pour la crédibilité.
2. R2 — Mauvaise interprétation des TDR. Cause fréquente de rejet.
3. R8 — Erreur financière. Impact direct sur la marge et la conformité.
4. R11 — Fuite de données. Impact juridique et réputationnel.
5. R20 — Absence de validation humaine. Risque de gouvernance majeur.

17.4 Revue des risques#

18. Actions des 48 prochaines heures#

Les dates ci-dessous sont calées sur le 22 octobre 2026. Si la validation intervient plus tard, recalculer en H+48 à partir de la date de validation.

18.1 Règles d'exécution#

1. Une action bloquante non terminée déclenche une escalade immédiate à Zied.
2. Les actions H1, H2, H3, H5, H6, H8, H9, H12, H13, H17 et H18 sont critiques.
3. Aucune action ne doit être marquée terminée sans preuve stockée.
4. Le point d'avancement se tient à 17h le 24 octobre 2026.

19. Décisions restant à prendre#

20. Informations manquantes#

20.1 Règle de traitement des informations manquantes#

Une information manquante ne doit jamais être remplie par une hypothèse présentée comme un fait. Elle doit être : identifiée, attribuée, datée, et si elle est bloquante, escaladée. Les informations non bloquantes peuvent être traitées en parallèle, mais elles doivent être signalées dans les livrables concernés.

Validation requise avant mise en œuvre#

Cette section doit être complétée et signée avant toute mise en production. Tant qu'elle n'est pas validée, le dispositif reste en phase de conception ou de pilote.

V.1 Validation par responsable#

V.2 Conditions de passage en production#

V.3 Décision finale de mise en œuvre#

Rappel final. Aucun appel d'offres ne doit être envoyé sur la base de cette feuille de route seule. L'envoi exige un dossier conforme, des références autorisées, une offre financière validée, un contrôle qualité, un PV de validation et une signature habilitée.