Premiers pas avec Devin

Créez un nouvel endpoint /users/stats qui renvoie un objet JSON avec le nombre d'utilisateurs et l'âge moyen à l'inscription.

Utilisez notre table users existante dans PostgreSQL.

Référencez l'endpoint /orders/stats dans statsController.js pour la structure des réponses.

Assurez-vous que le nouvel endpoint est couvert par la suite de tests StatsController.test.js.

Migrez logger.js de JavaScript vers TypeScript.

Nous avons déjà un tsconfig.json et une suite de tests LoggerTest.test.js pour la validation.

Assurez-vous qu'il compile sans erreurs et veillez à ne pas modifier la configuration existante !

Après la migration, vérifiez en :
1) exécutant `tsc` pour confirmer l'absence d'erreurs de typage
2) exécutant la suite de tests avec `npm test LoggerTest.test.js` pour vous assurer que tous les tests réussissent
3) vérifiant que tous les appels existants aux méthodes du logger dans l'ensemble du code fonctionnent toujours sans erreurs de typage.

Nous passons de pg à Sequelize (voir https://sequelize.org/api/v6/identifiers).

Veuillez mettre à jour les requêtes de `UserModel` pour utiliser les méthodes Sequelize.

Référez-vous à `OrderModel` pour voir comment nous procédons dans cette base de code.

Après l’implémentation, vérifiez :
1) en exécutant `npm run test:integration UserModel.test.js` pour vérifier que tous les tests d’intégration passent
2) en confirmant que les performances des requêtes ne se sont pas dégradées en vérifiant le temps d’exécution sur un jeu de données de test de 1000 utilisateurs
3) en validant que toutes les opérations CRUD maintiennent toujours l’intégrité des données en exécutant `npm run test:e2e user-flows.test.js`

## Vue d'ensemble
La tâche consiste à faire une pull request rapide vers un dépôt.
Comme il s'agit d'une PR « rapide », vous n'avez pas besoin d'exécuter de code ni de tester quoi que ce soit ; faites simplement une PR et l'utilisateur se chargera des tests. Votre seule responsabilité est de lire et d'écrire du code.

## Ce dont nous avons besoin de la part de l'utilisateur
- Le dépôt sur lequel créer une pull request

## Procédure
### Préparer votre espace de travail
1. Accédez au dépôt concerné sur votre machine (demandez des précisions à l'utilisateur si vous ne parvenez pas à l'identifier).
    - Basculez sur la branche principale et notez le nom de cette branche principale.
    - Basculez vers une nouvelle branche puisque vous allez créer une pull request. Le nom de la branche doit être au format `devin/<your-branch-name>/X` où X est un nombre aléatoire. Par exemple `devin/fix-popup/3234`. Exécutez `git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM` et remplacez `{branch-name}` par le nom de la branche que vous souhaitez créer.
2. Étudiez la demande, la base de code et planifiez les changements
    - Passez en revue les fichiers et sections de code les plus pertinents, en identifiant les extraits importants.
    - Informez l'utilisateur de votre plan
### Travailler sur la PR elle-même
3. Effectuez les modifications de code
    - Ne modifiez rien qui n'ait pas été spécifiquement demandé par l'utilisateur
4. Créez la PR
    - Validez (commit) et poussez les changements, puis informez l'utilisateur.
    - Consultez la section de conseils pour la commande exacte permettant de créer la PR
    - Créez une pull request et relisez la PR pour vous assurer qu'elle est correcte.
    - Assurez-vous que toutes les GitHub Actions passent avec succès et apportez les modifications nécessaires jusqu'à ce que ce soit le cas
    - Envoyez le lien de la PR à l'utilisateur et résumez ce que vous avez modifié.
5. Traitez tout retour de la revue ; renvoyez le lien de la PR à chaque fois que vous effectuez des modifications
    - Si vous devez faire des mises à jour, poussez simplement des commits supplémentaires sur la même branche ; ne créez pas une nouvelle branche


## Spécification de la tâche
- Le lien de la PR est inclus dans vos messages à l'utilisateur
- La PR a été relue après sa création
- La PR n'inclut aucun changement parasite
- La PR ne modifie rien qui n'ait pas été spécifiquement demandé par l'utilisateur
- La description de la PR doit inclure un résumé des changements, mis en forme sous forme de checklist
- La description de la PR doit mentionner que le code a été écrit sans tests, et inclure - [ ] Test the changes comme élément
- La description de la PR doit inclure le pied de page suivant : "This PR was written by [Devin](https://devin.ai/) :angel:"
- La description de la PR doit inclure toutes les métadonnées fournies par l'utilisateur (par exemple les tags de tickets Linear avec la syntaxe appropriée)
- La description de la PR ne doit pas être mal mise en forme (utilisez --body-file au lieu de --body si les sauts de ligne sont corrompus !)

## Actions interdites
- NE PAS essayer d'accéder à github.com via le navigateur, vous ne serez pas authentifié.
- Ne JAMAIS faire de force push sur les branches ! Préférez le merge au rebase afin de ne perdre aucun travail.
- NE PAS pousser directement sur la branche principale.

## Conseils et recommandations
- Vérifiez le nom de la branche principale (qui peut être `main` ou `master`) avec `git branch`.
- Pour les dépôts avec CI/CD sur GitHub Actions, vous pouvez consulter les journaux de build avec l'outil en ligne de commande gh (gh cli). Si l'on vous demande de corriger un build ou des erreurs de lint, commencez par examiner les journaux de build récents.
- Vérifiez `git status` avant de valider (commit) ou d'ajouter des fichiers.
- Utilisez `git diff` pour voir les changements que vous avez effectués avant de valider.
- Si vous mettez à jour un dépôt existant, utilisez `gh cli` pour créer des pull requests.
- Envoyez le lien de la PR à l'utilisateur chaque fois que vous la mettez à jour et demandez-lui de la relire à nouveau afin de lui faciliter la tâche.
- Vous devriez déjà être autorisé à accéder à tous les dépôts indiqués par l'utilisateur. Sinon, demandez à l'utilisateur de vous accorder l'accès.