Utiliser l'IA pour Gagner du Temps en Dev: Explications Détaillées

1. Aperçu général

Cet article aborde une question très pratique : comment utiliser l’IA (spécifiquement les LLM comme GPT ou Claude) pour gagner du temps dans le travail de développement quotidien, sans devenir un véritable “copie-colle en aveugle”. Vous découvrirez comment intégrer les LLM dans une application Spring Boot avec Spring AI, comment utiliser l’IA pour générer des tests, de la Javadoc, et quels pièges il faut éviter.

Après avoir lu cet article, vous serez capable d’écrire votre propre ChatClient appelant un LLM dans Spring Boot, de savoir comment rédiger des prompts pour chaque tâche (génération de code, review, écriture de tests), et de comprendre quand l’IA peut vraiment vous aider et quand elle ne fera que vous ralentir.

2. Où l’IA fait vraiment gagner du temps dans le travail de dev

L’IA n’est pas plus rapide que vous dans tous les cas. Il y a trois catégories de tâches où l’IA vaut vraiment le coup :

• Les tâches répétitives avec des modèles clairs : générer des DTO à partir d’entités, générer des getters/setters (même si l’IDE peut le faire), générer des cas de test boilerplate.
• Les tâches nécessitant une synthèse rapide d’informations : lire une longue stacktrace, résumer une PR, expliquer un bout de code legacy sans commentaires.
• Les tâches qui ont besoin d’une première version brouillon : rédiger une Javadoc, écrire un README, écrire une requête SQL complexe que vous affinerez ensuite.

En revanche, l’IA ne fait pas gagner de temps quand : vous ne comprenez pas bien le problème (un prompt flou produit un résultat flou), la logique métier est complexe et propre à votre entreprise, ou le code a besoin d’une grande précision en matière de sécurité/finance et que vous ne le revérifiez pas soigneusement.

Remarque : Si l’IA génère le code rapidement mais que la revue prend du temps, le temps total ne diminue pas, et peut même augmenter car vous devrez déboguer du code qui « semble correct mais dont la logique est fausse ».

3. Intégrer un LLM dans Spring Boot avec Spring AI

Plutôt que d’appeler l’API REST manuellement avec RestTemplate, vous utilisez Spring AI pour avoir un ChatClient pratique.

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-openai-spring-boot-starter</artifactId>
    <version>1.0.0</version>
</dependency>

Déclarez votre clé API dans application.properties :

spring.ai.openai.api-key=${OPENAI_API_KEY}
spring.ai.openai.chat.options.model=gpt-4o-mini

Créez un service wrappant ChatClient :

@Service
public class CodeAssistantService {

    private final ChatClient chatClient;

    public CodeAssistantService(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    public String explainStackTrace(String stackTrace) {
        String prompt = """
                Vous êtes un senior Java engineer. Expliquez brièvement la cause
                de la stacktrace suivante et proposez comment la corriger :
                %s
                """.formatted(stackTrace);

        return chatClient.prompt()
                .user(prompt)
                .call()
                .content();
    }
}

• ChatClient.Builder est auto-configuré par Spring Boot grâce au starter ci-dessus, vous l’injectez simplement.
• prompt().user(...).call().content() envoie le prompt et retourne la réponse sous forme de chaîne de caractères, sans avoir besoin de parser JSON à la main.
• La méthode explainStackTrace prend une longue stacktrace et retourne une explication concise — cela fait gagner 5-10 minutes de lecture de logs à chaque fois que vous déboguer une erreur bizarre.

Appelez-la dans un contrôleur :

@RestController
@RequestMapping("/api/assist")
public class CodeAssistantController {

    private final CodeAssistantService assistantService;

    public CodeAssistantController(CodeAssistantService assistantService) {
        this.assistantService = assistantService;
    }

    @PostMapping("/explain")
    public String explain(@RequestBody String stackTrace) {
        return assistantService.explainStackTrace(stackTrace);
    }
}

Un appel à POST /api/assist/explain avec une stacktrace NullPointerException en body retourne quelque chose comme :

L'erreur NullPointerException survient car la variable `customer` n'a pas
été initialisée avant d'appeler `customer.getEmail()`. Vérifiez OrderService
— le repository retourne peut-être null quand l'enregistrement n'est pas trouvé.
Il faudrait utiliser Optional ou vérifier null avant d'accéder à l'attribut.

4. Utiliser l’IA pour générer automatiquement des tests unitaires — exemple concret

L’une des tâches les plus chronophages est d’écrire des cas de test pour chaque branche logique. Supposons que vous ayez cette classe DiscountCalculator :

public class DiscountCalculator {

    public BigDecimal calculate(BigDecimal orderAmount, CustomerTier tier) {
        if (orderAmount.compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException("Order amount must be positive");
        }
        BigDecimal rate = switch (tier) {
            case GOLD -> new BigDecimal("0.15");
            case SILVER -> new BigDecimal("0.10");
            case BASIC -> new BigDecimal("0.05");
        };
        return orderAmount.multiply(rate).setScale(2, RoundingMode.HALF_UP);
    }
}

Exemple de prompt pour demander au LLM de générer des tests (vous collez la classe ci-dessus dans le prompt) :

Écrivez des tests unitaires JUnit 5 + AssertJ pour la classe DiscountCalculator.
Incluez les cas : GOLD, SILVER, BASIC, et le cas où orderAmount <= 0 doit lever
une IllegalArgumentException. Utilisez @ParameterizedTest si c'est approprié.

L’IA retourne généralement une version brouillon assez proche, que vous affinez selon le style de votre équipe :

class DiscountCalculatorTest {

    private final DiscountCalculator calculator = new DiscountCalculator();

    @ParameterizedTest
    @CsvSource({
            "GOLD, 100, 15.00",
            "SILVER, 100, 10.00",
            "BASIC, 100, 5.00"
    })
    void shouldCalculateDiscountByTier(CustomerTier tier, String amount, String expected) {
        BigDecimal result = calculator.calculate(new BigDecimal(amount), tier);

        assertThat(result).isEqualByComparingTo(new BigDecimal(expected));
    }

    @Test
    void shouldThrowWhenOrderAmountIsNotPositive() {
        assertThatThrownBy(() -> calculator.calculate(BigDecimal.ZERO, CustomerTier.GOLD))
                .isInstanceOf(IllegalArgumentException.class)
                .hasMessage("Order amount must be positive");
    }
}

• @ParameterizedTest + @CsvSource regroupe les 3 cas de tier dans un seul test, réduisant la duplication du code de test.
• La ligne assertThat(result).isEqualByComparingTo(...) compare les BigDecimal correctement (évite l’erreur d’equals distinguant la scale).
• Le dernier cas vérifie l’exception avec un message précis.

Ce que l’IA fait vite ici, c’est lister tous les cas limites (vous oublieriez facilement le cas orderAmount <= 0), mais ce que vous devez faire, c’est revérifier que les valeurs attendues sont correctes — l’IA se trompe souvent dans les calculs numériques.

5. Utiliser l’IA pour générer la Javadoc et résumer du code legacy

Avec du code ancien sans commentaires, l’IA résume plus vite que vous ne pouvez le lire ligne par ligne. Supposons que vous ayez ce morceau complexe :

public List<Order> filterEligibleOrders(List<Order> orders) {
    return orders.stream()
            .filter(o -> o.getStatus() == OrderStatus.PAID)
            .filter(o -> o.getCreatedAt().isAfter(LocalDate.now().minusDays(30)))
            .filter(o -> o.getItems().stream().anyMatch(Item::isRefundable))
            .toList();
}

Prompt : “Écrivez la Javadoc en français pour cette méthode, en précisant les 3 conditions de filtrage.” L’IA retourne :

/**
 * Filtre la liste des commandes éligibles au remboursement.
 * Conditions : la commande doit être au statut PAID, créée dans les 30 derniers
 * jours, et avoir au moins un article remboursable.
 *
 * @param orders la liste des commandes en entrée
 * @return la liste des commandes satisfaisant les trois conditions ci-dessus
 */

Cela fait gagner du temps pour l’onboarding des nouveaux développeurs sur une ancienne codebase — vous collez un tas de méthodes, l’IA retourne les Javadoc brouillons, vous ne corrigez que la terminologie métier erronée.

6. Automatiser la revue de code avec l’IA dans la CI

Vous pouvez ajouter une étape dans votre pipeline pour faire revérifier les diffs par l’IA avant qu’un humain les revise, afin de détecter les erreurs tôt. Voici un exemple simple en GitHub Actions qui appelle une API :

name: ai-review
on: [pull_request]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Get diff
        run: git diff origin/main...HEAD > diff.txt
      - name: Call AI review
        run: |
          curl -s https://api.openai.com/v1/chat/completions \
            -H "Authorization: Bearer ${{ secrets.OPENAI_API_KEY }}" \
            -H "Content-Type: application/json" \
            -d "$(jq -n --rawfile diff diff.txt \
              '{model:"gpt-4o-mini", messages:[{role:"user", content: ("Revoyez le diff Java suivant, ne signalez que les problèmes sérieux : " + $diff)}]}')" \
            > review.json

• git diff origin/main...HEAD récupère exactement la partie de code modifiée dans la PR, en évitant d’envoyer tout le repo (consomme des tokens, lent).
• jq -n --rawfile construit le corps JSON en toute sécurité, évitant les erreurs d’échappement des caractères spéciaux du code.
• Vous pouvez poster le résultat review.json en tant que commentaire sur la PR avec une autre étape.

Remarque : La revue par l’IA ne peut pas remplacer une revue par un senior. Elle détecte seulement les erreurs évidentes (null check manquants, catch Exception vides, injection SQL basique). Ne fusionnez pas une PR juste parce que l’IA l’a « approuvée ».

7. Erreurs courantes et quand ne pas utiliser l’IA

Quelques pièges réels quand on utilise les LLM dans un projet Java :

• Hallucination d’API inexistantes : l’IA peut suggérer d’appeler une méthode Order.markAsRefundable() alors que la classe réelle n’a pas cette méthode. Compilez toujours d’abord avant de faire confiance.
• Code syntaxiquement correct mais de mauvaise version : l’IA mélange souvent le style Java 8 (new ArrayList<>()) avec Java 21 (List.of(...)) de manière inconsistante — vous devez normaliser selon les conventions de codage de votre équipe.
• Fuite d’informations sensibles : ne collez pas des configs contenant des secrets, des chaînes de connexion ou des données réelles de clients dans un prompt envoyé à un service d’IA tiers.
• Prompt flou → output flou : « écrire des tests pour cette classe » produit un résultat bien plus superficiel qu’un prompt qui spécifie clairement les cas limites à couvrir.
• Quand ne pas utiliser l’IA : pour la logique de calcul d’intérêts, de taxes, ou toute partie relevant de la conformité où une petite erreur pose un problème légal — l’IA ne devrait être qu’un support pour écrire la structure, la partie calcul critique doit être vérifiée rigoureusement par quelqu’un ayant l’expertise métier avec des cas de test réels, pas générés par l’IA.

Une petite checklist à appliquer chaque fois que vous utilisez l’IA pour générer du code :

1. Le code compile-t-il ?
2. Les cas de test générés par l'IA couvrent-ils vraiment les cas limites réels,
   ou seulement les cas qui « semblent raisonnables » ?
3. Y a-t-il des informations sensibles qui auraient pu se retrouver dans le prompt ?
4. Le style du code correspond-il aux conventions actuelles de votre équipe ?

8. Conclusion

L’IA vous fait gagner du temps principalement sur les tâches répétitives et celles qui ont besoin d’une version brouillon rapide : générer des cas de test, expliquer les stacktraces, écrire la Javadoc, faire une première revue des diffs. Spring AI rend l’intégration des LLM dans une application Java simple avec juste quelques lignes de configuration et ChatClient.

Le point clé est que vous devez toujours revérifier attentivement chaque output — l’IA fait gagner du temps sur la rédaction, pas sur la compréhension et la vérification. Utilisé correctement, avec le bon niveau de confiance, vous pouvez réduire les nombreuses heures de travail répétitif chaque semaine sans compromettre la qualité du code.