This is a problem that is specific to your own code (which you didn't include), not generally solved by SFML.
However, as a babbys first demo you could start by doing some collision tests on the bounds of your sprites, like this:
if sprite_a.getGlobalBounds().intersects(sprite_b.getGlobalBounds()) {
// do your collision logic
Very soon though, you will want to decouple your rendering from your physics system. You should have some kind of game entity which interacts with the world, collides with other entities etc, but that doesn't know anything about rendering at all. Only as the last step in your update cycle does the "rendering system" kick in and draw all entities based on some chosen characteristics.
You should internalize the mantra of separating concerns. For example, collision detection doesn't need to know anything about sprites, and sprites also don't need to know about physics, sprites only need to know how to draw something. Ideally, the physics system would be a function which takes a static reference to the world and returns a new copy in which one frame's worth of movements and collisions have been resolved, then the rendering system would take reference to the array of game entities and return a frame buffer. But usually that's impractical and you will end up having some global mutable state that is modified frame by frame.
