Collaboration Framework Projet Web

Exigences relatives à la présélection

• Étendue du projet
• À propos du donneur d’ordre
• Délais
• Décision
• Indemnisation
• Après le pitch

Exigences relatives à la présélection

• Réflexions écrites sur la mission
• 3 exemples de travail
• Portrait de l’agence
• Lettre relative à l’adéquation de l’agence pour la mission
• Indemnisation

Au cours de la phase un de la procédure d’offre, le preneur d’ordre fournit déjà une prestation au donneur d’ordre: il se présente de façon détaillée (présentation de l’agence) et met sa proposition de solution par écrit. 
Dans la première phase, le donneur d’ordre ne doit pas exiger de coûts détaillés pour le projet; les tarifs d’agence et les taux horaires servent de valeurs de référence. Dans la première phase, aucune démarche stratégique ou aucune idée conceptuelle ne doit être demandée.

Exigences relatives à la sélection finale

• Discours de briefing
• Regard en arrière/Nouveau briefing
• Frais relatifs à une défaillance
• Entretien ultérieur

Exigences relatives à la sélection finale

•  Briefing
•  Regard en arrière/Nouveau briefing
• Présentation/Pitch

Il est important de comprendre la vision qu’a l’application et l’effet qu’elle doit avoir. La vision est définie à l’aide des ingrédients suivants:

• Personas: Qui sont les utilisateurs de l’application à créer? Il faut formuler ici précisément la forme des personas. De plus, il est judicieux de prioriser les personas – quels sont les plus importants pour nous
• Objectifs: Quel doit être le sens de l’application? Que souhaite-t-on atteindre avec cette application? Par expérience, nous savons que les objectifs sont la plupart du temps définis de manière imprécise. Une définition exacte aide toutefois à obtenir un ROI élevé. Il est également important de se poser la question suivante: pourquoi le donneur d’ordre poursuit-il cet objectif? Il est fréquent que la réponse au «pourquoi» donne très vite une explication sur la priorité liée à un objectif. Cela aide également (voir point précédent) à utiliser correctement le budget imparti.
• Besoins des personas: Quels sont les besoins des personas?
• Prévision: Le donneur d’ordre formule une prévision pour les 3-5 prochaines années.
• USP: Le donneur d’ordre définit la manière dont l’application doit être perçue par rapport à la concurrence.
• Systèmes périphériques et processus: Une explication est donnée sur la manière dont des processus doivent être mis en réseau en arrière-plan pour devenir plus efficaces dans les processus commerciaux, et quels systèmes auront une influence.
• Priorisation: Définir les objectifs qui ont la plus grande priorité. 
• Attentes: Il est souhaitable de clarifier en amont ce qui plairait au donneur d’ordre et à l’utilisateur final ou ce qui les décevrait.
• Ateliers/réunions: Le plus souvent, il est plus simple et plus rapide de ne pas formuler la vision par écrit, mais que le preneur d’ordre et le donneur d’ordre la clarifie au cours d’une réunion. Ainsi, toutes les parties prenantes comprennent la vision et peuvent ainsi s’identifier lors du développement. 

Afin que le preneur d’ordre comprenne le projet et puisse travailler de manière efficace, il est tenu de connaître le «User Journey». Il est recommandé de décrire les exigences fonctionnelles conformément au «User Journey».

Définir de manière horizontale et verticale

• Manière horizontale: Le donneur d’ordre et le preneur d’ordre décrivent dans les grandes lignes (en 5 à 7 points seulement) les étapes par lesquelles les utilisateurs doivent passer dans l’application. Cela pourrait p. ex. ressembler à ceci: 
  Aperçu Accueil – Clic et aperçu des offres d’emploi – Recherche par filtres – Vue d’ensemble des résultats – Clic et informations détaillées sur le poste – Clic et créer & envoyer une candidature. 
  Il s’agit des très grandes lignes des exigences relatives à l’application (Epics).
• Vertical: Ensuite, le preneur d’ordre et le donneur d’ordre vont ensemble dans les détails des divers Epics et formulent – mais uniquement lorsque cela est pertinent pour l’aspect commercial du projet – ce qui est précisément nécessaire pour la mise en œuvre de l’Epic. Par exemple:
  Vue d’ensemble des résultats
  • Il est important que l’enseigne de chaque société soit visible avec une offre d’emploi.
  • Les résultats proviennent d’une base de données d’un partenaire tiers.

Il en résulte un cahier des charges qui est d’une part horizontal – le voyage de l’utilisateur final à travers l’application, par des étapes de gauche à droite – et vertical – la manière dont les utilisateurs approfondissent chaque étape. Une carte de l’application est ainsi quasiment créée: elle permet au preneur d’ordre de comprendre les raisonnements et les souhaits du donneur d’ordre.

Il est très important que le donneur d’ordre transmette au preneur d’ordre toutes les informations possibles. À cet égard, il est hors de question d’être paresseux car cela peut nuire à la qualité des applications à créer.

Déclarations imprécises

Attention aux déclarations soulignées: de telles déclarations présentent un risque élevé dans le développement et, la plupart du temps, ne peuvent pas être appréciées du point de vue des dépenses. Elles peuvent donc mettre le projet en péril.

Il est donc recommandé:

• De permettre un accès transparent aux informations
• De planifier le budget pour des spikes ou une démonstration du concept – voir les définitions dans «Notions» ci-dessus.

Économiser dans ce contexte est risqué. De mauvaises surprises qui surviennent ultérieurement dans le projet se paient au prix fort.

Quels appareils sont utilisés par les clients finals – mobile (natifs? application web? réactifs?), tablette, ordinateur de bureau? Il est ainsi défini sur quel mode l’application doit être conçue et programmée.

Le donneur d’ordre doit définir

1. Dans quels navigateurs l’application doit tourner (y compris les exigences pour les terminaux mobiles)
2. sur quelles versions de navigateur une programmation optimale doit être présentée (certaines incohérences peuvent être autorisées)
3. Sur quelles versions de navigateur une programmation parfaite doit être présentée (chaque défaut doit être corrigé au pixel près); 
4. Sur quelles versions de navigateur elle doit tourner (indiquer la version la plus ancienne encore souhaitée)

À l’heure actuelle, la plupart des sociétés de développement web n’offrent aucun hébergement car cela demande une grande expertise – également en ce qui concerne la sécurité et les délais d’exécution. Malgré cela, le donneur d’ordre peut donner des renseignements sur:

• L’hébergeur en qui il a confiance
• Cloud oui / non
• Des environnements de développement idéaux afin que le développement interagisse parfaitement à différents niveaux et qu’il n’en résulte aucun problème même lors de la réception par le donneur d’ordre ou lors de la mise en exploitation.
• L’ensemble des prestations appropriées chez l’hébergeur, conformément aux exigences de l’application

Le niveau de sécurité qui est défini par le donneur d’ordre dépend très fortement de l’objectif de l’application. La mise en réseau des systèmes qui se cache derrière l’application utilisée par l’utilisateur constitue aussi une question pertinente en matière de technologie de sécurité (tout comme le cas de sites d’entreprises avec un login pour d’autres services).

Attention: Le RGPD (règlement général sur la protection des données) de l’UE est entré en vigueur en mai 2018 et s’applique dans toute la Suisse. Voir à ce sujet l’article Wikipedia sur le RGPD.

L’absence de barrières est une opportunité: en effet, une application qui n’a pas de barrières a en soi une meilleure expérience utilisateur (user experience) et est donc une meilleure application pour tous les utilisateurs.

Plus d’informations sur le sujet dans l’article Wikipedia sur l’Internet sans barrières et sur les normes et informations concrètes sur le site web relatif à l’utilisation de technologies sans barrières.

Le donneur d’ordre doit donc décider s’il souhaite une notation A, AA ou AAA (pour les institutions publiques, la notation AA est obligatoire). 

La rapidité d’une application peut être la base de son succès commercial. Évidemment, depuis déjà quelques années, l’utilisateur est habitué à des réponses très rapides des systèmes disponibles. Il faut définir ce que la rapidité de réponse du système signifie pour le succès du projet en tant qu’objectif de l’application.

L’architecture qui est choisie pour l’application et ses systèmes annexes ont une énorme influence sur la performance de l’application.

Le SEO et les analyses sont pertinents pour la réussite et doivent être intégrés dès le début dans les réflexions. Un atelier est utile pour définir des lignes directrices et des objectifs quantifiables.

L’utilisateur est habitué à des applications comme airbnb, youtube et des plates-formes similaires. Ces sites ont tous un guidage simple et intuitif de l’utilisateur. Cela définit la norme d’aujourd’hui. Il est essentiel de bien planifier et surtout de tester les fonctions de guidage de l’utilisateur. Elles influencent non seulement le succès de l’application de manière directe, mais aussi la réputation de la marque.

Une bonne expérience utilisateur est définie à l’aide de méthodes qui englobent également des recherches utilisateur ainsi que des tests utilisateur.

Des applications ayant une bonne expérience utilisateur seront avant tout définies par des critères objectifs (comme des recherches, des tests, etc.). 

La question qui se pose lors du développement de la conception visuelle est: «De quoi mon persona a-t-il besoin?» Les clients potentiels pour un produit de luxe s’attendent à une autre conception visuelle que des gestionnaires de stock qui doivent utiliser une application d’informations de logistique.

Il est recommandé de discuter de la qualité du code et des souhaits en matière de documentation et d’en convenir également (à propos d’une «Definition of Done»). Pourquoi?

• Le donneur d’ordre peut souhaiter attribuer le futur développement d’une application à un nouveau preneur d’ordre.
• En tant qu’agence, il faut souligner le fait qu’il est important que le développeur prenne du temps pour réaliser une programmation propre. Les frais relatifs à la correction des erreurs et à la maintenance en sont moindres.

Comment une bonne qualité du code est-elle assurée?

Le plus souvent, le donneur d’ordre lui-même n’est pas développeur et a donc des difficultés pour contrôler si la qualité du code est correcte. Sur la base des exigences suivantes, il est possible de s’assurer que les processus qui aboutissent à une bonne qualité du code sont respectés. 

• Révision du code par un autre développeur. Des erreurs que le développeur lui-même n’a pas remarquées lors de l’élaboration seront alors trouvées.
• Tests automatisés. Il convient de faire comprendre au donneur d’ordre que cela est une nécessité pour la pérennité de l’application et pour l’investissement.
• Tests manuels de chaque exigence mise en œuvre, réalisés par le preneur d’ordre et le donneur d’ordre peu de temps après le développement.

Une mixité est importante, ce qui signifie:

• Une bonne répartition entre la main-d’œuvre senior et junior. Il est important que de la main-d’œuvre senior fasse partie de l’équipe pour pouvoir répéter les expériences acquises. Ou non. Toutefois, il est tout aussi important que l’équipe comporte de la main-d’œuvre junior. En effet, elle apporte souvent des idées nouvelles.
• Une équipe transfonctionnelle (p. ex. développeur, spécialiste de l’expérience utilisateur, chef de projet, spécialiste en analyses, concepteur visuel, etc.). Si divers experts collaborent, cela doit avoir pour résultat une solution complète pour l’application.
• Une équipe fixe, au moins pendant la durée du projet. Ainsi, aucun savoir-faire n’est perdu pendant le développement. De plus, l’équipe reste concentrée sur l’objectif de l’application.
• Diversité des genres, des nationalités et d’autres critères. P. ex., pour une application sans barrières avec une notation AAA, il est important qu’un membre ait lui-même cet handicap. Ou pour une boutique qui vend des vêtements pour femmes, il est important d’avoir une grande part de femmes pour la conception et même pour le développement. Des équipes variées créent de meilleures applications car elles représentent en tant qu’équipe le petit monde de l’application.

On ne soulignera jamais assez combien une communication précise, sans obstacle, est importante entre l’équipe chargée de la mise en œuvre et le donneur d’ordre. Une communication faite au préalable par e-mail ne suffit pas. Des projets web nécessitent des outils de communication qui sont orientés vers les besoins de tels projets et qui peuvent être utilisés simplement et rapidement par tous. Les décisions qui sont importantes pour le succès de l’application et qui servent de base de connaissances même après la finalisation du projet sont également documentées dans de tels outils. Par conséquent, des e-mails ou des appels téléphoniques ne suffisent pas. Les outils suivants sont recommandés:

• Atlassian Confluence: Ce logiciel sert à documenter des concepts, en incluant les exigences non-fonctionnelles, la Definition of Done, l’organisation du projet, etc.
• Atlassian Jira: Ce système permet de documenter tout le catalogue des travaux. Les deux parties, à savoir le preneur d’ordre et le donneur d’ordre, y ont accès. Les diverses parties de mandat y sont définies, discutées, commentées et finalement retirées.
• Slack ou outil de chat similaire: Il permet un échange très rapide entre le preneur d’ordre et le donneur d’ordre. Dans ce contexte s’appliquent une série de règles qui doivent être convenues entre les partenaires afin que les travaux ne soient pas perturbés en permanence.  Les avantages l’emportent cependant sur ce risque.
• Réunions régulières lors desquelles des décisions importantes sont prises et les prochaines étapes du projet sont définies dans des échanges personnels. (voir également à ce sujet «Procédure»)

Par principe, il existe deux méthodes: Cascade ou agile

Conformément au «rapport 2016 sur les tendances & benchmarks» de Swiss Q, tous les projets agiles enregistrent une réussite de 60%, contre 45% seulement pour la méthode en cascade.

Dans une grande majorité, le développement de logiciels est une tâche complète et donc non planifiable à l’avance. La méthode en cascade ne convient pas à des projets complexes.

La méthode agile – même si elle semble un peu bizarre au début – promet une plus grande réussite du projet, un meilleur retour sur investissement, une mise sur le marché plus rapide, une meilleure qualité de code ainsi qu’une application plus en phase avec les attentes de l’utilisateur.

Comme nous l’avons dit: la grande majorité des projets de développement de logiciels est complexe, avec un grand nombre d’inconnues, et nécessite donc la méthode agile.

Lors de la procédure de sélection du preneur d’ordre, une prestation d’assistance et de maintenance peut déjà être demandée. La manière dont l’application est documentée au fil du développement est alors souvent mise en évidence. Seule une application bien documentée peut être transmise sans erreurs au service d’assistance.  Plus l’application est complexe, plus les coûts de la maintenance sont élevés.

Les points importants dans le SLA sont:

• La manière dont les mises à jour des versions sont gérées
• La manière dont les temps de travail sont utilisés (piquet le week-end ou uniquement aux heures de bureau)
• La manière dont les critères sont définis pour le service d’assistance (criticité des défauts)
• La manière dont de petites ou de grandes extensions de l’application sont gérées

Le preneur d’ordre doit présenter au donneur d’ordre un modèle du contrat d’assistance et de maintenance dès la phase d’offre et être en mesure de faire une estimation approximative des coûts.