Réponse en bref
Une présentation terminée n'est pas forcément un projet exploitable. Ce guide propose quatre contrôles distincts et une feuille de recette fondée sur des preuves.
Ce que valider signifie quand quatre métiers partagent un brief
Une checklist de remise de projet numérique décrit ce que le client pourra réellement exploiter après le départ du prestataire. Pour un projet réunissant identité de marque, site web, flux d'IA et marketing, elle doit nommer chaque actif promis, son emplacement de travail, la personne qui l'approuve et un test qu'une nouvelle recrue pourra répéter. Il s'agit d'une méthode d'achat, non du récit d'un résultat obtenu par un client de VITON13. Imaginons une petite marque de vêtements lançant une identité et un formulaire de demande : l'exemple est fictif et ne suppose aucun gain de ventes ou de conversion. La bonne question n'est pas de savoir si la présentation finale paraît achevée, mais si l'entreprise peut ouvrir, modifier, mesurer et maintenir ce qu'elle a payé.
Partez du brief signé et de la dernière version écrite du périmètre. Prévoyez quatre lignes de recette distinctes, même si un seul studio coordonnait le tout. Un logo exporté ne prouve pas que le site fonctionne ; une page en ligne ne prouve pas que le client maîtrise son compte publicitaire ; une bonne réponse d'IA ne prouve pas le traitement sûr d'une demande ambiguë. Désignez une personne décisionnaire côté client et un responsable de remise par ligne. Notez la version examinée, le lien de preuve, le relecteur, la date et le statut : accepté, défaut, dépendance ou changement proposé. Le processus public de VITON13 Studio sépare périmètre écrit, revue humaine, retouches, livraison et assistance ; la feuille rend ces limites vérifiables.
Marque : un système modifiable, pas seulement un PDF séduisant
Pour la marque, listez le logo maître, ses variantes approuvées, les valeurs de couleurs, la typographie, la direction iconographique, les règles d'usage et les applications prévues au brief. Distinguez la présentation lisible du fichier source qu'un autre designer pourra reprendre. Un PDF montre l'identité approuvée ; un fichier de travail bien préparé et les informations de licence des polices permettent de produire une nouvelle enseigne ou un modèle social sans tout reconstruire. Si le contrat ne promet que des exports, n'ajoutez pas silencieusement les sources au test final. Signalez plutôt le manque opérationnel et convenez si le paquet modifiable change le périmètre. Indiquez où vit chaque fichier et ouvrez-le depuis un compte contrôlé par le client.
Testez l'identité dans les usages pour lesquels elle a été conçue. Dans notre lancement fictif, placez le logo sur un en-tête mobile clair, une étiquette foncée, un avatar étroit et une signature d'e-mail. Vérifiez que la plus petite taille prévue reste lisible et que couleurs et noms de polices correspondent à la documentation. Comparez le résultat au brief signé, pas à une préférence de dernière minute non chiffrée. La ligne relative aux droits doit préciser ce qui est original, les polices ou images nécessitant une licence tierce, qui la détient et les limites territoriales ou de canal effectivement convenues. C'est une question contractuelle, pas un avis juridique : recevoir un fichier n'accorde pas automatiquement tous les usages futurs.
Site : sources, production et parcours utilisateurs réels
Pour le site, demandez le dépôt source convenu, les consignes de déploiement, les détenteurs de l'hébergement et du domaine, l'inventaire de configuration sans secrets, la façon de modifier les contenus et le contact en cas de retour arrière. Ne mettez jamais de mots de passe dans la feuille ; indiquez qui donne les accès et quand ils seront renouvelés. Selon GitHub, le transfert change l'administration du dépôt ; webhooks, secrets et clés de déploiement restent associés, tandis que certaines fonctions dépendent de l'offre du nouveau propriétaire. Vérifiez séparément le propriétaire, les administrateurs, la connexion externe de déploiement et la sauvegarde. Une archive ZIP de code peut satisfaire un contrat limité, mais ne remplace pas une méthode d'exploitation.
Effectuez les essais sur le site livré, pas seulement dans une prévisualisation. Sur téléphone et au clavier, cherchez un produit ou service, envoyez une demande valide, déclenchez une erreur de champ obligatoire et trouvez les informations de confidentialité ou de retour pertinentes. Pour chaque essai, notez URL, appareil, date, comportement attendu et comportement observé. Contrôlez liens et formulaires avec les contenus définitifs ; si plusieurs langues sont comprises, parcourez au moins une version traduite. La Web Accessibility Initiative du W3C recommande d'évaluer l'accessibilité tôt et régulièrement et souligne qu'aucun outil automatique ne peut, seul, la déterminer. Joignez donc observations manuelles et rapport automatique. Une anomalie reste ouverte jusqu'à sa correction et son nouveau test, même si la capture du lancement est belle.
Flux d'IA : cas d'échec et reprise en main humaine
Un flux d'IA requiert ses propres preuves, car ses réponses peuvent varier alors que l'interface reste identique. Définissez la tâche autorisée, les données consultables, l'action possible et le moment où une personne doit confirmer ou corriger. Pour notre marque fictive, un assistant pourrait préparer une réponse sur le stock, mais ne devrait pas inventer une disponibilité ou promettre une livraison non confirmée par l'inventaire. Essayez une entrée ordinaire, une donnée absente, des notes contradictoires, une demande hors périmètre et une sollicitation d'information restreinte. Enregistrez le comportement, l'attendu du relecteur et l'efficacité de l'escalade. N'utilisez pas de vraies données clients dans le jeu d'essai.
Le cadre de gestion des risques de l'IA du NIST réunit gouverner, cartographier, mesurer et gérer comme fonctions continues, non comme une étiquette de conformité ponctuelle. Traduisez cela en fiche d'exploitation : responsable nommé, sources admises, version du prompt ou de la configuration, cas de test, action du relecteur, contact d'incident et moyen d'arrêter le flux. Convenez de qui paie le modèle ou l'automatisation, qui peut modifier les réglages et quoi faire si le fournisseur change ses conditions. Une démonstration réussie ne prouve ni l'exactitude future ni un retour sur investissement garanti. Valider signifie que le jeu de tests convenu est passé et que les limites restent visibles, avec une personne capable d'arrêter le système en cas d'incertitude.
Marketing : comptes, créations et définitions de mesure
La ligne marketing relie la stratégie aux comptes dans lesquels l'activité se poursuivra. Listez cible et message approuvés, créations, calendrier de publication, plan de suivi, définition des rapports et comptes utilisés. Pour chaque canal, notez si le client détient le compte, quels utilisateurs du prestataire y accèdent, leurs droits nécessaires et qui peut les retirer. L'aide Google Analytics explique que les utilisateurs peuvent être ajoutés au niveau du compte ou de la propriété, ce qui détermine leur accès. D'où un test concret : un administrateur autorisé du client se connecte, voit la bonne propriété, vérifie les événements convenus et confirme que le rôle de l'agence n'est pas trop large. Une capture de tableau de bord envoyée par mail ne remplace pas cette vérification.
Séparez budget publicitaire, production créative, abonnements logiciels et honoraires du studio. Un nombre dans un tableau de bord ne suffit pas à déclarer une campagne réussie sans événement, période et règle d'attribution définis. Dans notre exemple, l'entreprise pourrait choisir la demande complétée comme événement principal ; c'est un choix de mesure proposé, pas la preuve d'une hausse des demandes. Notez l'état initial de la mesure, les hypothèses sur balises et consentement et la personne chargée de contrôler les données après lancement. Fournissez les créations modifiables lorsque le contrat le prévoit, les versions finales approuvées et un calendrier compréhensible par l'équipe suivante. Retirez l'accès du prestataire après confirmation du contrôle client et fin de l'assistance prévue.
Propriété, frais externes, retouches et limites d'assistance
Le propriétaire d'un actif n'est pas forcément celui du compte associé. Le client peut détenir un fichier de marque alors qu'une autre personne paie la police ; il peut posséder le domaine mais laisser l'accès DNS à l'ancienne agence. Pour l'hébergement, les domaines, polices, images sous licence, API d'IA, outils d'analyse et canaux payants réellement utilisés, notez le détenteur, l'échéance, le coût récurrent, la résiliation et l'export possible. Indiquez 'inconnu' pour un frais non vérifié, jamais 'inclus' par défaut. Pour le dépôt, choisissez entre transfert, accès partagé et organisation cliente dès le départ. Le guide GitHub sert à examiner les effets du transfert, non à imposer celui-ci à tous les projets.
Séparez défaut et demande nouvelle. Un défaut signifie qu'un élément livré échoue à une règle écrite ; une modification ajoute ou change une exigence déjà approuvée. Le journal des retours doit contenir preuve, priorité, responsable et résolution proposée. Sur la même feuille, inscrivez les tours de retouche contractuels, délais de réponse, début et fin de l'assistance et travaux couverts. Si l'absence d'un fichier source, d'une licence ou d'un accès empêche l'essai, marquez la ligne 'bloquée', non 'acceptée'. Évitez une seule case 'projet terminé' alors que plusieurs éléments restent ouverts. Ce suivi protège équitablement client et prestataire contre les interprétations ultérieures d'un accord oral.
Une feuille de recette fictive à adapter
Créez une ligne par livrable avec les colonnes suivantes : chantier ; résultat convenu ; actif et version ; responsable client ; responsable prestataire ; lien de preuve ; test et résultat attendu ; résultat observé ; statut ; frais ou licence externe ; prochaine action et date. Il s'agit d'un modèle hypothétique, pas du compte rendu d'un client VITON13. Ligne A : marque, identité approuvée version 1, responsable créatif client, source ouverte dans le compte client, acceptée après les essais d'usage convenus. Ligne B : site, formulaire version 2, responsable des opérations, envois valides et invalides testés sur mobile, défaut car le message d'erreur prête à confusion. Le statut découle d'un test observable et non d'une impression.
Ligne C : IA, assistant de brouillon version 1, relecteur des opérations, des informations contradictoires sur les stocks doivent être escaladées ; bloquée jusqu'à démonstration de la file de validation humaine. Ligne D : marketing, propriété Analytics et calendrier, administrateur client ; accès vérifié mais définition d'un événement encore ouverte, donc dépendance plutôt qu'acceptation. Ajoutez une ligne pour les frais récurrents et les responsables de renouvellement. Une autre personne doit pouvoir comprendre les mêmes preuves sans avoir assisté à la présentation. Si le prestataire utilise un autre format, conservez les champs, pas la mise en page. L'essentiel est la trace des promesses, essais, écarts et prochaines décisions.
Clore le projet sans effacer les questions ouvertes
À la revue finale, parcourez la feuille ligne par ligne. Acceptez ce qui satisfait au test écrit, fixez une date de contre-vérification des défauts, chiffrez les changements séparément et attribuez les accès manquants à une personne nommée. Demandez à l'administrateur client de tester lui-même la connexion au lieu de lui transmettre un mot de passe. Conservez le manifeste final, les références de licence, consignes et validations dans un espace contrôlé par le client. Indiquez contact d'assistance et date exacte de fin de prise en charge, en distinguant maintenance et travail nouveau. Si un service se renouvelle automatiquement, quelqu'un doit le savoir avant la prochaine facture. La remise est achevée quand le destinataire sait exploiter le résultat, pas quand un dossier est envoyé.
Cette méthode garde aussi les affirmations éditoriales à leur juste portée. Une checklist ou une norme ne garantit ni site performant, ni IA sûre, ni marketing rentable. GitHub, Google Analytics, NIST et W3C décrivent des pratiques précises de plateforme ou d'évaluation ; l'équipe doit les appliquer à son contrat et à ses risques. Le processus public de VITON13 prévoit périmètre, exclusions et retouches écrits avant le début, puis contrôle, livraison et assistance. Ce guide transforme la séquence en dossier de preuves pour le client. Apportez la feuille à la prochaine revue, demandez les preuves manquantes et gardez ouvertes les lignes non résolues jusqu'à décision de la personne responsable.
Checklist pratique
- Désignez une personne décisionnaire côté client et un responsable de chaque remise.
- Associez chaque actif promis à un emplacement, une version, un format et un test reproductible.
- Vérifiez les accès détenus par le client au code, à l'hébergement, au domaine et aux comptes de mesure.
- Testez un parcours normal et un parcours d'erreur sur le site et dans le flux IA.
- Consignez abonnements externes, titulaires des licences, échéances et responsables des résiliations.
- Séparez les éléments acceptés, les défauts et les demandes de changement facturées à part.
Questions et réponses
Que doit contenir une checklist de remise de projet ?
Notez le résultat convenu, la version et l'emplacement de chaque livrable, le détenteur des accès, un test reproductible, les défauts ouverts, les frais tiers, les droits ou limites de licence et la fin de l'assistance. Une capture d'écran ne prouve pas que le client pourra exploiter le résultat.
Le client doit-il posséder le dépôt GitHub ?
Cela dépend du contrat et du mode d'hébergement. Si le dépôt doit lui revenir, il peut être créé dans son organisation dès le départ ou transféré ensuite. GitHub documente les conditions et conséquences du transfert ; contrôlez les administrateurs et intégrations après l'opération.
Une démonstration suffit-elle pour valider un flux d'IA ?
Non. Essayez des entrées ordinaires, des données manquantes et contradictoires, un point de validation humaine nommé et une voie d'escalade. Notez l'attendu et l'observé. Une démonstration soignée montre une possibilité, pas la fiabilité du flux dans les conditions de travail quotidiennes.