Respecter les standards

Les bonnes pratiques de vos développeurs, vérifiées dans le code

Un standard, ce sont des règles que l'équipe s'engage à suivre : faire relire le code par des outils d'analyse, lancer les tests à chaque modification, configurer l'hébergement et le dépôt GitLab comme convenu. Encore faut-il qu'elles soient réellement en place.

smartplatform.cloud lit vos dépôts GitLab et vérifie chaque règle. Le rapport dit ce qui est conforme, ce qui reste à corriger, et pourquoi la règle existe.

Parlez-nous de votre besoin

Rapport de règles

Votre application

12 novembre 2026

2Non conforme
1Inconnu
20Conforme

espace-clientÀ corriger

main · Version analysée a3c91f85 du 11 nov.

PHPStan est configuré au niveau 10phpstan.neon

Configuré au niveau 6. Le niveau maximal détecte les erreurs de type avant la production.

Les tests sont lancés par la CI.gitlab-ci.yml

À chaque modification, avec une couverture de 78 % publiée dans GitLab.

PHP contraint à la version de production.env

Version de production non déclarée : la règle ne peut pas conclure.

Le constat

Ce qui dérape sans standards vérifiés

Les bonnes pratiques se décident en début de projet. Sans vérification, elles s'effritent sans que personne ne le voie.

  • 1

    Des outils installés, jamais lancés

    Un outil d'analyse configuré mais que la chaîne de livraison ne lance pas ne vérifie rien. Sur le papier, tout est en place.

  • 2

    Des exceptions qui s'accumulent

    Chaque erreur mise de côté « pour plus tard » rejoint une liste que personne ne relit. La dette grossit sans bruit.

  • 3

    Des versions qui divergent

    Le code vise une version de PHP ou de Node, la production en fait tourner une autre. L'écart se découvre en production.

  • 4

    Chaque projet à sa façon

    Avec plusieurs équipes et plusieurs projets, chacun applique ses propres règles. Impossible de comparer, difficile de reprendre un projet.

Les règles

Ce qui est vérifié, dépôt par dépôt

Dans le code, dans la configuration de l'hébergement et dans le dépôt GitLab. Chaque règle dit en une phrase pourquoi elle existe, et renvoie à la documentation pour la mettre en place.

  • L'analyse du code

    Le code relu par des outils avant la production : erreurs de type, appels dangereux interdits, failles d'injection, règles du code front.

  • Les tests

    Les tests lancés à chaque modification, une vérification que les pages répondent, et le taux de couverture publié dans GitLab.

  • Les versions de production

    PHP, Node et MySQL contraints aux versions qui tournent réellement en production, et un seul gestionnaire de paquets.

  • La mise en forme

    Le code écrit de la même façon par toute l'équipe, et vérifié automatiquement à chaque livraison.

  • La configuration de l'hébergement

    Les tâches planifiées, les variables d'environnement et la mémoire allouée, déclarées avec le projet : la production tourne comme prévu, et se reconstruit à l'identique.

  • Le dépôt GitLab

    Les branches protégées, les règles de fusion et le paramétrage du dépôt : aucune modification n'arrive en production sans relecture.

Ce qui rend la mesure fiable

Le résultat, pas l'intention

  • Ce qui est dans le dépôt

    Une règle juge ce qui est réellement en place dans le dépôt, que l'outil ait été installé par notre socle ou à la main.

  • Rien ne s'exécute

    La plateforme lit les fichiers du dépôt par GitLab. Elle ne lance aucune commande sur votre code.

  • Inconnu n'est pas conforme

    Quand un fichier manque ou ne se lit pas, la règle s'affiche « inconnu », à corriger. Un silence ne vaut jamais conformité.

  • Corrigé, c'est constaté

    Une règle n'est corrigée que lorsqu'une nouvelle vérification du dépôt la trouve conforme.

Ce que vous aimeriez vérifier dans le code de vos logiciels

Dites-nous quelles règles comptent pour vous : vos besoins orientent les prochaines vérifications de la plateforme.

Parlez-nous de votre besoin