---
# System prepended metadata

title: 'Conceptialisation de l''application web (WebApp) [for-pro.ch](https://for-pro.ch/)'
tags: [for-pro]

---

---
tags: for-pro
---

# Conceptialisation de l'application web (WebApp) [for-pro.ch](https://for-pro.ch/)

## Reviews 20230207

### 1. Objectifs

Dans cette partie, pour moi, nous devons penser "support de communication". L'objectif global est de nous outil orienté vers des personnes qui sont pour l'instant extérieur au projet. En opposition à la version 3, qui devra, à mon sens, être une phase orienté personnel, répondre à des problématiques interne.

Objectif de la plateforme, à étayer par/avec ForPro : 

- Description pour servir de support de communication (par exemple pour les conseiller.e.xs d'orientation, les parents, …) ;

- communication sur l'espace :
    - Connexions à une liste de réseaux sociaux (input/output).  
Ici, il faudra définir les réseaux qui vont être utilisé (c'est à définir avec les points en 2. Cibles).

- Passé/futur, montrer que c'est vivant ;
    - timeline de la V1

- inscription étudiant.e.xs(?) ;
    
- diffusion d'offres d'emplois ;
    - espace pour communiquer sur les offres d'emplois. Comme défini en introduction de ce point, il faut penser la plateforme V2 comme un outil de communication. Nous aurons besoin de mettre en avant les offres d'emplois, pour inciter les personnes à venir. En V3, cette section sera certainement à redéfinir.

- Redirection/Intégration pour répondre à ces offres d'emplois.
    - comment diffuser les offres, comment y répondre, comment recruter. Par exemple, les HES rassemblent toutes leurs offres à un endroit. La HEAD, (qui fait partie des HES) duplique ces offres pour une communication à son. Échelle. Comment ceci va se passer pour ForPro?
        - au niveau du bâtiment (ex : administration),
        - des 'départements' (ex : MakerLab, LearningLab)
        - besoin propre à chacun de ces départements (ex: profs pour l'école d'horlogerie)

### 2. Personnes cibles

Pour faire la base des persona. Il nous faut bien définir les types de personnes qui se connecteront à cette plateforme. Ils seront, à mon sens, tout.e.xs extérieur à ForPro. Mais ceci est à valider par ForPro. Pour moi, comme dit précédemment, nous devons d'abord nous concentrer sur comment se faire connaitre et comprendre. Il faut déjà "remplir ForPro" avant de créer des outils pour le fonctionnement en interne. (à valider, je manque de vision pour ce point).

Liste, à étayer aussi par/avec ForPro:
- Conseiller.e.xs d'orientation ;
    - donner les moyens de comprendre ce qu'est forpro, l'école d'horlogerie, les ateliers, pour bien cibler à qui partager ces informations.
- Futur professionnel l.e.xs;
    - pour l'hôtel entreprises.
- professionnell.e.xs en activité ;
    - pour l'hôtel entreprises là aussi
- parent.e.xs / étudiant.e.xs.
        - parent.e.x qui veut montrer à son enfant ;
        - parent.e.x qui veut être rassuré,
        - …

### 3. Site (à venir)
Définir une structure/arborescence avec les points précédents.

### 4. SEO/SEA (définir quand ceci arrive)
La phase V2 va être orientée **communication**. Il faut intégrer rapidement l'équipe référencement et outil de communication au projet. La structure, le design de la plateforme va être influencée par cette partie.

- Search Engine Optimization (référencement naturel)
Ensemble des techniques mises en œuvre pour améliorer la position d'un site web sur les pages de résultats des moteurs de recherche

- Search Engine Advertising
Le SEA est un système qui vise à placer une annonce publicitaire en bonne position sur les moteurs de recherche, dans la partie payante.

### 5. Publicité (à venir)

Cf. partie 4


# microservices vs application monolithe

## ressources
- https://jamstack.org/
- Bon article qui explique [microservices-architecture](https://www.atlassian.com/fr/microservices/microservices-architecture/microservices-vs-monolith#:~:text=Une%20app%20monolithique%20est%20con%C3%A7ue,plus%20petits%20et%20d%C3%A9ployables%20ind%C3%A9pendamment.)


## définition


### application monolithe

###### (2022, janvier 18). Wikipédia. 18 janvier 18, 2022, fr.wikipedia.org/wiki/Application_monolithe.

En développement logiciel, une application monolithe ou une architecture monolithe est une application dont l'ensemble du code et des fonctionnalités est implémenté dans un seul programme.


### microservices

###### (2022, janvier 18). Wikipédia. 18 janvier 18, 2022, fr.wikipedia.org/wiki/Microservices.

En informatique, les microservices sont une technique de développement logiciel […] qui structure une application comme un ensemble de services […]. Les microservices indépendants communiquent les uns avec les autres en utilisant des API indépendantes du langage de programmation.

Des API REST sont souvent employées pour relier chaque microservice aux autres. <u>Un avantage avancé est que lors d'un besoin critique de mise à jour d'une ressource, seul le microservice contenant cette ressource sera mis à jour, l'ensemble de l'application restant compatible avec la modification, contrairement à la totalité de l'application dans une architecture classique […].</u>


## intro
Netflix est l'un des pionnières des infrastructures logiciel basé sur des microservices basé sur le Cloud. Ils ont dû faire ceci pour répondre a la croissance de la plateforme, qui devenait trop compliqué à gérer avant, car réalisé sur un principe d'application monolitique.

Nous avons actuellement :
- application web, pour l'affichage des données pour les clients ;
- backend Kirby, accessible avec une API;
- service Infomaniak pour l'inscription à la newsletter;

On pourra :

1. brancher autant de services qu'on veut sur l'application web (WebApp)
2. créer outils pour interagir avec la base de donnée Kirby, par exemple une application mobile (ex : la HEAD a actuellement un site et une application web, les données doivent être dupliquées ; soucis de synchronisation et duplication du travail)
3. chaque service et application (Web App, application mobile, …) peut facilement être mis à jour ou remplacé, sans avoir tout à refaire.


## pro/cons (extrait de l'article du premier point, c'est pour vous faire gagner du temps)

### architecture monolithique

#### pro
- Déploiement facile
- Développement 
- Performances
- Tests simplifiés
- Débogage facile

#### cons

- Vitesse de développement plus lente
- Évolutivité : vous ne pouvez pas mettre à l'échelle des composants individuels.
- Fiabilité : si une erreur survient dans un module, elle peut affecter la disponibilité de l'ensemble de l'app.
- Obstacle à l'adoption de la technologie : les changements apportés au framework ou au langage affectent l'ensemble de l'app, ce qui les rend souvent coûteux et chronophages.
- Manque de flexibilité
- Déploiement


### microservices

#### pro

- Agilité
- Évolutivité flexible
- Déploiement continu
- Facilité d'administration et de test
- Déploiement indépendant
- Flexibilité technologique
- Fiabilité élevée
- Équipes satisfaites : (autonomie des services/ dessectuers je dirais ici. Par exemple, chaque département de forpro poura utiliser l'outil qu'il veut pour gérer son administration [reservation, etc…])


#### con

**comme on va le voir, c'est que des soucis de dev, et pas des utilisateurs… Donc positif pour ceux qui vont utiliser nos/les apps**

- Développement tentaculaire
- Coûts d'infrastructure exponentiels  
-> du au multiple services qu'on va utiliser, mais c'est pas un facteur pour ForPro
- Frais organisationnels supplémentaires  
-> idem
- Défis de débogage
- Manque de standardisation
- Manque de responsabilité claire

## mots clefs
- travailler de manière ajile
- Évolutivité flexible
- dévelopement continu (faire des mises a jour régulieère sur des petites évolution)
- fléxibilité
- JAMstack (je détestes ce mot ^^) mas ceci signifie

## schéma (extrait du premier articles)

![](https://i.imgur.com/87HcYP3.png)
![](https://i.imgur.com/DbdyN9m.png)
![](https://i.imgur.com/q2zjUXP.png)
