skip_to_content
  1. Home
  2. Connaissances

Collaboration Framework Projet Web

Avec le Collaboration Framework, Swico s’engage en faveur d’une plus grande transparence dans le lancement de projets web et crée ainsi une base orientée vers la pratique pour une bonne collaboration.

Le Collaboration Framework définit des lignes directrices, des bases juridiques et des bonnes pratiques dans un même contexte. Les acteurs du marché élaborent des contenus pratiques du cadre concerné et les développent de manière continue. 

Lors de tables rondes, les défis actuels font l’objet de discussions et sont intégrés et développés par consensus dans le Collaboration Framework.
Les points de friction relevés dans des projets web au niveau de la collaboration entre les donneurs d’ordre et les preneurs d’ordre y sont mis en évidence et présentés de façon à contribuer à mieux comprendre les intérêts d’autrui.

RFP ou Pitch

Correctement posée, une RFP ou une présentation à la concurrence (pitch) peut constituer le début d’une collaboration à long terme. Dans la pratique, et en raison de conventions manquantes ou imprécises après le pitch ou la remise de la RFP, il peut exister des conflits qui peuvent conduire à de longs contentieux, et avant tout à une insatisfaction chez les deux parties.

Request for Proposal (RFP)

Il est renoncé à un pitch; au lieu de cela, une offre est demandée. Des agences sont sélectionnées sur la base des offres pour aborder le projet dans ses détails. La notion de RFP englobe également des requêtes sur lesquelles une décision est directement prise

La RFP demande au donneur d’ordre de mettre au point une solution répondant aux exigences et de la chiffrer. Avec la RFP, le fournisseur soumet, en plus des chiffres, des premières propositions de mises en œuvre et des solutions possibles pour la mission qui a été confiée au donneur d’ordre, sans rémunération/rétribution.

Présentations à la concurrence (pitch)

Des présentations à la concurrence sont rédigées afin de sélectionner la bonne agence pour un projet ou un budget donné. Dans un briefing, le donneur d’ordre formule le cahier des charges du pitch. Cela constitue la base du pitch et est l’interface essentielle entre l’entreprise et les agences.

Sur la base du briefing, le donneur d’ordre formule ses objectifs concrets et le cahier des charges précis et les remet aux agences. Le briefing doit faire l’objet d’une discussion avec l’organe décisionnaire de l’entreprise.

Sélection d’agences appropriées pour le pitch

Sur la base des présentations et des propositions, le donneur d’ordre sélectionne trois agences à l’aide de critères d’aptitude pondérés qui, selon lui, conviennent au mieux à la mission, et les invite à la phase 2 de la procédure de sélection.

Phase 2

Dans la deuxième phase de la procédure de pitch, le donneur d’ordre doit obtenir une compréhension approfondie sur la méthode de travail et la démarche du preneur d’ordre. Le preneur d’ordre présente alors des solutions concrètes.

Briefing oral et écrit

Un briefing personnel est nécessaire au début de la deuxième phase. Une compréhension mutuelle de la mission et la connaissance de l’éventuel futur partenaire sont aussi importants pour le bon choix de l’agence que le travail fourni dans le pitch.

Honoraires appropriés pour le pitch

Les honoraires pour le pitch doivent être définis en amont. Chaque preneur d’ordre doit se demander s’il souhaite continuer aux conditions définies. L’objectif des honoraires n’est pas de supporter les coûts de l’agence. La présence de fonds disponibles pour le projet doit également être garantie. En d’autres termes, il ne s’agit pas simplement de parler «pour le plaisir».

Si des frais relatifs à une défaillance sont estimés à CHF 3000.–, le donneur d’ordre investit CHF 9000.– pour effectuer son choix.

En plus des frais relatifs à une défaillance, l’utilisation possible d’un concept, mais sans sa mise en œuvre par le preneur d’ordre, peut être réglementée. Si par exemple le preneur d’ordre a élaboré un très bon concept mais que la chimie n’est pas bonne entre les deux parties, le donneur d’ordre peut mettre en œuvre le concept avec un autre partenaire moyennant paiement d’honoraires. Le droit d’utilisation est transféré avec le versement des honoraires.

Les agences perdantes touchent dans tous les cas de figure des honoraires de pitch (également nommés contribution symbolique).

Exigences relatives à la présentation

Présentation du concept, de l’élaboration et de la faisabilité, avec des prototypes cliquables pour le site web ou l’application.

Alternatives au Pitch/RFP

Des présentations à la concurrence peuvent être évitées, des «avant-projets» avec les preneurs d’ordre potentiels contournés. Ces projets plutôt petits couvrent une partie du projet à réaliser. Lors de la collaboration personnelle à une tâche concrète, il devient rapidement évident pour les deux parties si une collaboration est conforme à l’objectif ou non. Il est déterminant de savoir si l’équipe de projet partage les mêmes valeurs et les mêmes idées, si elle est compatible en tant qu’équipe et, évidemment, si la qualité des artefacts répond aux besoins et aux exigences. Cet aspect de la collaboration et la manière dont les personnes travaillent ensemble du côté du donneur d’ordre et du preneur d’ordre se perdent presque totalement avec le pitch car seuls les faits, le budget et les résultats comptent.

Exigences relatives aux lignes directrices

Des valeurs empiriques démontrent qu’au moins 30% du cahier des charges est modifié au cours du projet: des exigences sont supprimées ou leur contenu est modifié, et de nouvelles exigences viennent s’ajouter. Dans la plupart des cas, des projets de logiciels ne peuvent pas être planifiés du fait que de nombreuses inconnues apparaissent pendant le projet ou que les circonstances évoluent. Les erreurs classiques les plus fréquentes:

Personas ou vision non existants   

  • Erreur: La vision ou les personas de l’application ne sont pas clairs.
  • Risque: Les exigences sont ainsi erronées ou définies de manière imprécise. On ne s’y investit donc pas correctement. 
  • Bonne pratique: Définir clairement la vision, les personas & leurs besoins au début du projet et toujours s’orienter en conséquence.

Vers un degré de détail plus élevé des exigences

  • Erreur: Détailler les exigences dans les moindres détails. 
  • Risque: Modifier continuellement les informations et les faits au cours du projet. De nouvelles informations s’ajouteraient. Si l’on s’en tient aux exigences détaillées, il existe un risque de passer à côté de l’objectif. 
  • Bonne pratique: Les exigences fonctionnelles sont introduites d’une manière horizontale (User Journey) et verticale (fonctionnalités individuelles extrêmement importantes). Les détails sont redéfinis. 

Manque de participation du donneur d’ordre lors du projet

  • Erreur: Le donneur d’ordre prend du temps uniquement à la fin du projet pour effectuer les tests. 
  • Risque: De ce fait, on voit uniquement à la fin ce qui a été oublié, ce qui manque encore ou ce qui ne convient pas aux personas. 
  • Bonne pratique: À des intervalles définis et en concertation avec le donneur d’ordre, développer, tester et ajuster en permanence, selon la business value la plus élevée. 

Notions

  • Donneur d’ordre 
    Il s’agit de la partie qui donne le mandat de développement d’une application ou d’un site web. 
  • Preneur d’ordre
    Il s’agit de la partie qui développe l’application ou le site web sur mandat. 
  • Client/utilisateur final
    Désigne la personne qui utilise l’application en dernier lieu.
  • Équipe transfonctionnelle
    Se compose de développeurs, de spécialistes de l’expérience utilisateur, de concepteurs, de chefs de projet et d’autres experts importants pour le projet. Ils s’occupent du produit à élaborer et travaillent en étroite collaboration avec le donneur d’ordre. 
  • Persona
    Représentation archétypique de l’utilisateur de l’application ou du site web. 
  • Epics
    Grands thèmes, grossièrement présentés, d’une application ainsi que de lots de travaux. 
  • Exigences fonctionnelles (FA)
    Les exigences fonctionnelles décrivent des fonctionnalités souhaitées (ce que le système doit faire/doit pouvoir faire) d’un système ou d’un produit, de leurs données ou de leur comportement. Les exigences non-fonctionnelles sont des exigences relatives à la qualité avec laquelle la fonctionnalité requise doit être fournie.  
  • Exigences non fonctionnelles (NFA)
    Les exigences non-fonctionnelles décrivent la manière dont le système doit fournir la prestation de manière correcte; elles sont souvent comprises comme des conditions marginales et des caractéristiques de qualité. Un exemple: le produit doit répondre à l’utilisateur en une seconde.
  • User Journey
    Un User Journey reprend toutes les étapes qu’emprunte un utilisateur pour atteindre un certain objectif avec un système interactif. Il se compose la plupart du temps d’un nombre de pages de sites web et de points de décision qui amènent l’utilisateur d’une étape à l’autre. Les User Journeys sont illustrés dans les User Journey Maps qui présentent le parcours de manière détaillée avec toutes les étapes et toutes les expériences. 

Composantes à définir

Pour pouvoir réaliser un projet web, il existe des composantes qui doivent être définies au préalable: 

  • La vision, ainsi que les personas 
    De leur définition naît la compréhension entre le donneur d’ordre et le preneur d’ordre sur les objectifs, l’expérience utilisateur et la conception de l’application. 
  • Exigences fonctionnelles (FA) – voir notions
    Définition grossière des fonctionnalités que l’application doit contenir.
  • Exigences non fonctionnelles (NFA) – voir notions
    Il s’agit d’exigences qui concernent toute l’application et qui s’appliquent lors de la mise en œuvre d’exigences fonctionnelles. 

Des questions sur le Collaboration Framework?

palmisani_giancarlo_2553__weiss_ganz.jpg

Giancarlo Palmisani

Responsable des prestations de l’association / membre de la direction
+41 44 446 90 85
E-Mail

Politique de Swico en matière de témoins informatiques
Swico utilise ses propres témoins informatiques et les cookies de tiers à des fins de marketing, de profilage et d'analyse et pour faciliter la navigation sur le site Web. Veuillez lire notre protection données. Cliquez sur FERMER pour accepter les témoins informatiques.