refactor(ui): switch tags to clickable false by default

Related to #427 (closed)

What does this MR do and why?

Une grande partie des tags sont utilisés pour afficher de l'information. L'input clickable a été marque comme true par défaut ce qui cause le problème suivant à beaucoup d'endroit

Niveau développement, cela a plus de sens de devoir indiquer [clickable]="true" lorsqu'une action est passée plutôt [clickable]="false" lorsque rien n'est passé.

Malheuresment, il n'est pas possible de se baser sur l'output afin de vérifer si il existe : action?.emit($event)

Screenshots or screen recordings

Enregistrement_de_l_écran_2024-01-24_à_17.56.45

How to set up and validate locally (or on alpha)

List all steps to set up and validate the changes on local environment.

---

MR acceptance checklist

To be completed by the chosen reviewer.

Quality -

• For the code that this change impacts, I believe that the automated tests validate functionality that is highly important to users. If the existing automated tests do not cover this functionality, I have added the necessary additional tests or I have added an issue to describe the automation testing gap and linked it to this MR.
• I have made sure that the sonar quality coverage is up to standards.
• I have considered the impact of this change on the front-end, back-end, and database portions of the system where appropriate and applied.
• I have tested this MR in all supported browsers or determined that this testing is not needed.
• I have confirmed that this change is backwards compatible across updates (migrate up needs a migrate down), or I have decided that this does not apply.

Performance, reliability and availability

• I am confident that this MR does not harm performance, or I have asked a reviewer to help assess the performance impact.
• I have considered the scalability risk based on future predicted growth.

Documentation

• The MR is named after the desired squash commit to feed the changelog linked to the current milestone.
• I have added/updated documentation (also updated if the changes feature a deprecation) or I have decided that documentation changes are not needed for this MR.

Security

• I have confirmed that if this MR does not contains any sensitive informations hidden in the changes.